crypto et noyau linux

remy a écrit :

bonjour

je suis à la recherche de liens info sur les librairies
exploitables dans le noyau linux par un driver
pour faire de la crypto

en gros j'ai besoin de tester la primalité
de structures qui gèrent les grands nombres
et de l'opération modulo

j'ai bien trouvé crypto.h
http://www.google.fr/codesearch?hl=fr&q=file:(/%7C%5E)linux/crypto%5C.h%24&as_package=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.1.tar.bz2&is_navigation=1

mais je suis un peu bouché
ou en manque d'exemples

Comme déjà dit sur f.c.l.c coller toute une bibliothèque de
calcul en multi précision dans le noyau est une mauvaise idée...
Je ne vois toujours pas en quoi ton machin a le moindre intérêt
à fournir un périphérique plutôt que d'être entièrement en
espace user... Mais bon, un truc qui vient de sortir pourrait
t'intéresser : CUSE (Char Device In User Space) :

http://groups.google.com/group/linux.kernel/msg/83b45431e6f2d17e

YBM a écrit :

remy a écrit :

bonjour

je suis à la recherche de liens info sur les librairies
exploitables dans le noyau linux par un driver
pour faire de la crypto

en gros j'ai besoin de tester la primalité
de structures qui gèrent les grands nombres
et de l'opération modulo

j'ai bien trouvé crypto.h
http://www.google.fr/codesearch?hl=fr&q=file:(/%7C%5E)linux/crypto%5C.h%24&as_package=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.1.tar.bz2&is_navigation=1

mais je suis un peu bouché
ou en manque d'exemples

Comme déjà dit sur f.c.l.c coller toute une bibliothèque de
calcul en multi précision dans le noyau est une mauvaise idée...
Je ne vois toujours pas en quoi ton machin a le moindre intérêt
à fournir un périphérique plutôt que d'être entièrement en
espace user... Mais bon, un truc qui vient de sortir pourrait
t'intéresser : CUSE (Char Device In User Space) :

http://groups.google.com/group/linux.kernel/msg/83b45431e6f2d17e

merci pour le lien

remy

remy a écrit :

YBM a écrit :

remy a écrit :

bonjour

je suis à la recherche de liens info sur les librairies
exploitables dans le noyau linux par un driver
pour faire de la crypto

en gros j'ai besoin de tester la primalité
de structures qui gèrent les grands nombres
et de l'opération modulo

j'ai bien trouvé crypto.h
http://www.google.fr/codesearch?hl=fr&q=file:(/%7C%5E)linux/crypto%5C.h%24&as_package=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.1.tar.bz2&is_navigation=1

mais je suis un peu bouché
ou en manque d'exemples

Comme déjà dit sur f.c.l.c coller toute une bibliothèque de
calcul en multi précision dans le noyau est une mauvaise idée...
Je ne vois toujours pas en quoi ton machin a le moindre intérêt
à fournir un périphérique plutôt que d'être entièrement en
espace user... Mais bon, un truc qui vient de sortir pourrait
t'intéresser : CUSE (Char Device In User Space) :

http://groups.google.com/group/linux.kernel/msg/83b45431e6f2d17e

merci pour le lien

De rien.

Cependant je n'arrive vraiment pas à imaginer une seule raison
valable pour laquelle ton machin aléatoire devrait être, ne
serait-ce qu'en partie, dans le noyau et fournir un périphérique
dans /dev.

Les seules raisons pour être dans le noyau sont 1) besoin
d'un accès privilégié au matériel, 2) besoin d'interagir
de façon "intime" avec un pilote dans le noyau ou 3) performances
(ou temps réel dur)
(les puristes des micro-noyaux éjectent 2) et 3) à la poubelle).
Par ex :

Pilote son/reseau/disque : 1)
Systèmes de fichiers : 2) et 3)
TCP/IP : 2) et 3)
Firewall : 2) et 3)
/dev/random : 1)
IPSEC : 2) et 3)
etc.

Pour ton générateur aléatoire basé sur des (grands) nombres premiers
je ne vois rien de semblable.

YBM a écrit :

remy a écrit :

YBM a écrit :

remy a écrit :

bonjour

je suis à la recherche de liens info sur les librairies
exploitables dans le noyau linux par un driver
pour faire de la crypto

en gros j'ai besoin de tester la primalité
de structures qui gèrent les grands nombres
et de l'opération modulo

j'ai bien trouvé crypto.h
http://www.google.fr/codesearch?hl=fr&q=file:(/%7C%5E)linux/crypto%5C.h%24&as_package=http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.1.tar.bz2&is_navigation=1

mais je suis un peu bouché
ou en manque d'exemples

Comme déjà dit sur f.c.l.c coller toute une bibliothèque de
calcul en multi précision dans le noyau est une mauvaise idée...
Je ne vois toujours pas en quoi ton machin a le moindre intérêt
à fournir un périphérique plutôt que d'être entièrement en
espace user... Mais bon, un truc qui vient de sortir pourrait
t'intéresser : CUSE (Char Device In User Space) :

http://groups.google.com/group/linux.kernel/msg/83b45431e6f2d17e

merci pour le lien

De rien.

Cependant je n'arrive vraiment pas à imaginer une seule raison
valable pour laquelle ton machin aléatoire devrait être, ne
serait-ce qu'en partie, dans le noyau et fournir un périphérique
dans /dev.

Les seules raisons pour être dans le noyau sont 1) besoin
d'un accès privilégié au matériel, 2) besoin d'interagir
de façon "intime" avec un pilote dans le noyau ou 3) performances
(ou temps réel dur)
(les puristes des micro-noyaux éjectent 2) et 3) à la poubelle).
Par ex :

Pilote son/reseau/disque : 1)
Systèmes de fichiers : 2) et 3)
TCP/IP : 2) et 3)
Firewall : 2) et 3)
/dev/random : 1)
IPSEC : 2) et 3)
etc.

Pour ton générateur aléatoire basé sur des (grands) nombres premiers
je ne vois rien de semblable.

il n'y a pas de raison objective basée sur une contrainte tangible
dit différemment je cherche à coller à une pratique ou à faire un peu
comme tout le monde

je cherche à mettre mon truc dans /dev/ parce qu'il y a déjà un
/dev/random il ne faut pas chercher plus loin

dans tous les cas j'ai mon driver qui tourne

je vais coder mon truc en c et à un moment donné j'essaierai de faire
converger les deux bouts de code


remy

remy a écrit :

YBM a écrit :

...

Pour ton générateur aléatoire basé sur des (grands) nombres premiers
je ne vois rien de semblable.

il n'y a pas de raison objective basée sur une contrainte tangible
dit différemment je cherche à coller à une pratique ou à faire un peu
comme tout le monde

Donc aucune raison, et NON ce n'est pas "faire un peu comme
tout le monde".

je cherche à mettre mon truc dans /dev/ parce qu'il y a déjà un
/dev/random il ne faut pas chercher plus loin

Tu aurais commencer à te demander pourquoi le générateur derrière
/dev/random est un pilote : uniquement parce qu'il se base sur des
évènements matériels, et que ce sont les pilotes de périphériques
qui sont en mesure d'obtenir ces informations afin d'augmenter le
pool d'entropie. Le cas de /dev/urandom est plus problématique,
mais vu comment il est simple, c'est pas trop grave de le
mettre dans le noyau, même si un simple service en mode utilisateur
aurait pu faire de même. C'est le côté un peu opportuniste
d'UNIX qui laisse faire ça.

dans tous les cas j'ai mon driver qui tourne

Déjà ? Tu as réussi à faire l'immense bêtise de lier libgmp
à un module ? J'en doute...

je vais coder mon truc en c et à un moment donné j'essaierai de faire
converger les deux bouts de code

Ce qui n'a pas le moindre intérêt : fais en plutôt un service de ton
bousin.

YBM a écrit :

remy a écrit :

YBM a écrit :

...

Pour ton générateur aléatoire basé sur des (grands) nombres premiers
je ne vois rien de semblable.

il n'y a pas de raison objective basée sur une contrainte tangible
dit différemment je cherche à coller à une pratique ou à faire un peu
comme tout le monde

Donc aucune raison, et NON ce n'est pas "faire un peu comme
tout le monde".

oui complètement d'accord

tu peux même rajouter qu'il n'y aura personne qui utilisera se truc
donc c'est pas très grave

mais comme je suis borné ...

je cherche à mettre mon truc dans /dev/ parce qu'il y a déjà un
/dev/random il ne faut pas chercher plus loin

Tu aurais commencer à te demander pourquoi le générateur derrière
/dev/random est un pilote : uniquement parce qu'il se base sur des
évènements matériels, et que ce sont les pilotes de périphériques
qui sont en mesure d'obtenir ces informations afin d'augmenter le
pool d'entropie.

ah ben merde alors ça ....

Le cas de /dev/urandom est plus problématique,

mais vu comment il est simple, c'est pas trop grave de le
mettre dans le noyau, même si un simple service en mode utilisateur
aurait pu faire de même. C'est le côté un peu opportuniste
d'UNIX qui laisse faire ça.

dans tous les cas j'ai mon driver qui tourne

Déjà ? Tu as réussi à faire l'immense bêtise de lier libgmp
à un module ? J'en doute...

non non c'est pas de mon niveau, mon c'est antédiluvien
juste un truc qui dit coucou et qui se charge
et c'est déjà pas mal, cela fait plus de 20 ans que je n'ai pas touché
un compilateur c

j'ai bien essayé de lire les makefile du noyau mais

je ne crois pas qu'il faille avoir un esprit sain pour
aller se perdre dans le dédale

point de départ
make -C ${KERNEL_SOURCE} M=${PWD} modules

je me suis arrêté
/usr/src/linux-headers-2.6.20/scripts/Makefile.modpost

il y avait longtemps que je n'avais pas vu un tel enchevêtrement

je vais coder mon truc en c et à un moment donné j'essaierai de faire
converger les deux bouts de code

Ce qui n'a pas le moindre intérêt : fais en plutôt un service de ton
bousin.

je code mon bousin avec gmp
et après je réfléchirais j'en ai marre de lire du code