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

On Mar 4, 3:08 am, whygee



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

| si tu lis 1 trame.


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% )



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


 > alors cela n'a rien E0% voir.


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'.



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.



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 ?


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.


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


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


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


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



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%.



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%".


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.



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



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 ?



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



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.



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.



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


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.



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.



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.



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.



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 ...



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


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


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.



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 ?



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.



Trop facile !

Jean-Christophe a ecrit


... 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

On Mar 4, 2:32 pm, "rvlegran"

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


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



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 ?

Jean-Christophe a ecrit

Ce sont toujours des discussions interessantes :oÞ



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

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

zoliii !

on les trouve oF9% ?


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

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

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)


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

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

Bonjour les trolls ! :-)


ah ben quand on tient un bon sujet, on le lE2%che pas :-)


par le principe simple que si la donnE9%e y est,
on peut l'extraire (je dis pas comment)


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".


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.



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


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 :-)



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)


soit environ 17000 messages par jour,
dont on connait la monotonicitE9% du contenu.
miam miam :-)



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.



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% :-)


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%...


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


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.


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.




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 !



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 /


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%.


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.



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



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...


haha c'est mignon ^_^


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

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 :-/


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%.


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".


ah tiens, un autre angle de "discussion" apparait...


(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.


"arbitrairement" : lE0% est la faiblesse du raisonnement.
en crypto, le seul arbitraire est la clE9%.


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.


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 ?



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.


alors code-le pour le prouver :-)



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



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.


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 :-)



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.


mais E7%a ne le rend pas plus sFB%r



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.


montre-le :-)


possible, mais moins sFB%r.


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%.


et parce que tu sors des sentiers battus, tu te prends
dans les ronces, et au mieux tu rE9%inventes la roue.


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.


la prudence ?


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

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


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



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.


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.


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" :-)


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 ;-)=



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.


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

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%



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.



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.

Jean-Christophe a ecrit


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

rvlegran a tapoté du bout de ses petites papattes :


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 a ecrit


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

"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% :-)


yg

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

On Mar 3, 11:38A0%pm, LeLapin



Tout E0% fait d'accord avec toi.

On Mar 3, 11:20 pm, "rvlegran"



Salut HervE9%.



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 ...



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.



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

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

Emile a tapoté du bout de ses petites papattes :


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

On Mar 4, 12:06 am, Emile



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.



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.