Version imprimable
Bonjour,
Je voudrais trouver un algo pour générer un code sur un certain nombre de caractères (14 par exemple). C'est un ensemble de plusieurs codes que je voudrais avoir. Il faut que les code soit tous différents à chaque fois. C'est comme pour les carte de recharge de crédit pour telephone portable.
Merci.
si les codes sont pas réellement secrest il n'y a qu'à mettre
YYYYMMDDhhmmss ce qui fait exactement 14 chars.
On peut le comoufler un peu avec 1 XOR.
Il ne faut pas emettre 2 codes dans la même seconde.
Salut, voilà ma proposition
- 00000000000000
- 00000000000001
- 00000000000002
- 00000000000003
- 00000000000004
- 00000000000005
- 00000000000006
- ...
Plus sérieusement (car je suppose que ce ne n'est pas ce que tu veux même si dans l'absolu cela répond à ta question telle qu'elle est formulée) : quelles sont les infos dont tu disposes pour générer ce code ? Cela doit-il être totalement aléatoire ?
Il existe de nombreux générateur d'aléas (dont certain hardware pour rendre encore plus difficile la prévision). Je suppose que ces valeurs aléatoires seront rentrées dans une base de données pour vérifier la validité, donc l'unicité peut être facilement garantie par une simple recherche dans la base de donnée.
ce que je voudrais peut etre un de ces generateur d'alea comme tu dis. Car il faut qu'on puisse le plus difficilement détécter la suite des nombres.
Donne moi le nom d'un stp.
L'idée de YYMMHHSS... n'est pas interressante car il suffit de faire la remarque et de faire des etntatives pour tomber sur un code valide, ce que je veux eviter. J'espere que vous comprenez ce que je veux dire.
Tout dépend de ce à quoi tu veux résister
un petit malin qui va passer deux heures dessus en ayant qu'un seul cas sous les yeux ou tous les ordinateurs de la NSA pendant 6 mois en possédant un corpus de 10000 exemples ?
Sans doute entre les deux, je suppose.
Une solution très simple est de tirer aléatoirement 12 de tes 14 positions, les deux dernières étant une check sum plus ou moins compliquée des précédents cela te fait 1 chance sur 65536 de tomber dessus au hasard, si tu prends une check sum sur 4 positions : 1 chance sur 4 294 967 296, mais moins de cas différents
Pour qu'un générateur d'aléa soit suffisament solide il faut qu'il y est de vrai éléments aléatoires qui soient introduit, un simple algorithme ne peut suffire. Sous Linux il existe, en standard, un générateur aléatoire généralement considéré comme sûr, mais relativement lent, cela dépend donc de la quantité de données que tu veux générer. Pour les dispositifs hardware tu peux voir par exemple http://www.comscire.com/Home/Citation:
Envoyé par quiyai
De manière générale, ton truc correspond (plus ou moins) à un numéro incrémental, par exemple sur 32 bits (=4 milliards de codes possibles, ça devrait aller dans un premier temps ;-)), passé à un crypteur avec surchiffrement.
En simplifiant un peu, un caractère alphanumérique peut coder entre 5 et 6 bits suivant si l'on tient compte de la casse des caractères ou pas. Dans ton cas, disons que non : 14 caractères à 5 bits par caractère, ça fait 70 bits, dont "seulement" 32 sont utiles... Ca commence très bien, plus de la moitié des bits sont là juste pour brouiller les pistes ! :-D
Tu vas donc utiliser ce numéro incrémental N, et un nombre E (Empreinte) généré par le passage de N à une fonction à sens unique H (fonction de hachage), par exemple un CRC32.
Pour brouiller les pistes, tu vas crypter N avec une fonction réversible et bijective : un nombre 32 bits est crypté vers un autre nombre 32 bits, avec bijection entre les deux espaces. Il est donc possible, bien sûr, de générer une "table de craquage" du code, mais ce n'est pas trivial, et ce genre de truc est assez volumineux (16 Go, quand même...).
Bon, une fois N crypté, il devient forcément plus difficile à "trouver", mais il n'est pas encore une "clé". Pour ça, on va surchiffer.
Nous sommes donc à 64 bits utilisés en concaténant N et E, il en reste 6 à "remplir".
Le but est de trouver une formule permettant d'entremêler N et E au niveau bit, en fonction de la valeur des 6 autres bits (qui seront, eux, générés aléatoirement). La seule difficulté consiste à trouver une formule aisément réversible.
Si, en plus, tu t'amuses à recrypter tout ça, ça devient assez infernal de retrouver N et E, et donc de trouver un code valide "au hasard" !
Enfin, tu découpes tes 70 bits par paquets de 5, qui te serviront à générer un caractère alphanumérique à chaque fois. Comme tu as (26+10)=36 caractères pour stocker 32 valeurs, tu peux ici aussi introduire un surchiffrement : par exemple, décider arbitrairement que si le 1er caractère est une lettre, alors les codes "9" et "Z" seront identiques, etc, etc... Ca va te fournir 4 caractères "étranges", qui auront pour ton algorithme la même valeur que 4 autres, mais qui peuvent perturber un peu plus le travail de craquage.
Enfin, tu as ton code à 14 caractères. Pour le valider, tu effectue toutes les opérations en sens inverse, pour finir par aboutir à N et E. Comme tu connais la fonction H (ce qui n'est pas le cas du péquin moyen), ton test de validité de clé consiste, au bilan final, à recalculer H(N) et vérifier qu'il est bien égal à E. Si c'est le cas, ton code est valide. Sinon, il est rejeté.
Bien sûr, le même principe est applicable avec n'importe quel nombre : par exemple, ton nombre "N" peut contenir, sur les 16 bits de poids fort, un nombre 100% aléatoire qui n'est là que pour rendre les clés "uniques". Les 16 bits de poids faible peuvent contenir une valeur utile, comme le nombre d'unités de téléphone à créditer sur le compte... ;-) Là aussi, tu peux encore surchiffrer (c'est d'ailleurs ce que fait la partie "aléatoire"), ou "disséminer" les bits formant le montant de recharge dans le mot de 32 bits en fonction des valeurs aléatoires obtenues ! :twisted:
Comme tu le vois, le principe général est de brouiller au maximum les pistes, et de n'utiliser au maximum que la moitié des bits "disponibles" pour ton information réelle, de manière à obtenir un surchiffrement intéressant et difficile à craquer.