NUMERO DE CARTE BANCAIRE ET DE CLEF DE RIB
EgorLetov
Messages postés
13
Date d'inscription
lundi 24 février 2003
Statut
Membre
Dernière intervention
7 septembre 2003
-
2 sept. 2003 à 11:15
skone007 Messages postés 166 Date d'inscription mercredi 24 avril 2002 Statut Membre Dernière intervention 23 juin 2009 - 27 déc. 2007 à 18:36
skone007 Messages postés 166 Date d'inscription mercredi 24 avril 2002 Statut Membre Dernière intervention 23 juin 2009 - 27 déc. 2007 à 18:36
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/11320-numero-de-carte-bancaire-et-de-clef-de-rib
https://codes-sources.commentcamarche.net/source/11320-numero-de-carte-bancaire-et-de-clef-de-rib
27 déc. 2007 à 18:36
27 déc. 2007 à 16:45
4 févr. 2006 à 14:07
On crée d'abord une clé de hachage du message à signer ''M'', à l'aide d'un algorithme sûr non inversible (sans collision connue), par exemple MD5(''M'') ou SHA-1(''M'').
Puis on crypte cette clé de hachage avec la clé privée du signataire (que seul lui connait). Cela crée la signature. On transmet alors le message (en clair ou non), accompagné de la signature.
Celui qui reçoit le message le décrypte éventuellement, puis en calcule aussi la clé de hachage. Il compare cette clé de hachage avec la clé obtenue en décryptant la signature avec la clé publique du signataire. Ces deux clés de hachage doivent être égales.
Si le message est modifié, la clé de hachage va changer. Et on sait que le message vient bien du signataire car seul lui connait la clé privée qui a pu encrypter avec succès la signature desorte que son décryptage avec la clé publique donne la clé de hachage voulue.
4 févr. 2006 à 13:55
Un algorithme de cryptage dit "à clé publique" utilise en fait une paire de clés: la clé publique sert pour encrypter, mais une clé privée est nécessaire pour décrypter, ou bien la même clé privée peut servir à encrypter, la clé publique servant à décrypter.
Dans le cas de l'algorithme LUHN, il n'y a aucune clé privée. Ce n'est PAS du cryptage/chiffrement, et même pas un bon code de contrôle d'erreur (comme CRC). Ces deux algorithmes ne sont que des sommes de contrôle, mais ils n'empêchent pas l'altération du message et le remplacement par un autre message considéré valide, ils ne permettent pas la non-répudiation, ce ne sont donc pas des clés de hachage, et donc pas non plus des signatures, et ils ne cachent pas un message (puisqu'il n'y a pas de décryptage!)
Oh et puis: les codes RIB (modulo 97) et LUHN ne sont pas américains. L'algorithme de cryptage RSA par contre l'est (et a fait l'objet d'un brevet américain, dont la licence est gratuite mais pas pour les applications dérivées, et d'une création de société américaine du même nom, faisant de RSA une marque commerciale). L'algorithme RSA est un algorithme de cryptage à clé publique (asymétrique). Le DES est un algorithme de cryptage symétrique, à clé privée.
3 févr. 2006 à 11:12
Bref celui qui arrive a decomposé un trse grand nombre en nombre premier dans un temps raisonnable aura retourner le RSA...
2 févr. 2006 à 20:49
La clé RIB est simplement un nombre entre 01 et 97 tel que le nombre final (banque guichet compte clé) est divisible par 97. Cela ne dispense pas de fournir un numéro de banque valide (la liste est publique), un numéro de guichet correct (partiellement public ou facile à obtenir), un numéro de compte existant dans la banque (plus difficile) et le BON numéro de guichet pour ce compte. De plus la connaissance d'un RIB ne suffit pas pour effectuer n'importe quelle opération (d'ailleurs de nombreux commerçants et associations publient leur RIB... ou le numéro IBAN européen qui enest une simple extension avec le préfixe FR suivi d'un code à deux chiffres identifiant le type d'établissement banquaire ou financier, et terminé par une autre clé à 2 chiffres calculée aussi sur le modulo 97 de l'ensemble)
Sinon pour le numéro de carte de crédit (à 13, 15 ou 16 chiffres suivant le type de carte), le dernier chiffre est la clé de "LUHN" (pas de LUTH!) et son calcul est encore plus basique. Les premiers chiffres identifient le type de carte (MC/EC, AmEx, Visa, DC...) puis parfois l'établissement banquaire émetteur (mais rarement en France car les numéros sont attribués en commun par le GIE carte bancaire pour toutes les banques qui éditent des cartes avec le logo CB, qu'elles soient internationales d'un réseau Eurocard ou Visa voire AmEx, ou cartes simples utilisables que dans une seule banque).
L'algorithme du LUHN est utilisé aussi pour les cartes de crédit révolving (souvent distribuées comme des cartes "magasin" dans une offre initiale de crédit "gratuit" ou "3 fois sans frais", par exemple les cartes Cofidis, Cofinoga, Cetelem, dont celles distribuées par FNAC, Surcouf, Virgin, Auchan, Monoprix, La Redoute...). Attention: ces dernières ne sont protégées par aucun code secret lors du paiement (Mieux vaut ne jamais les garder dans son portefeuille et les détruire si on ne s'en sert pas). Contrairement à une croyance courante, ce ne sont pas des cartes de fidélité, et elles ne donnent droit à aucun avantage du magasin (les "cadeaux" sont des points attribués par l'organisme de crédit en fonction des crédits réalisés lors des achats, il est impossible decumuler des points pour obtenir quelquechose de décent sans s'endetter lourdement, et le montant des loyers du crédit sont horriblement plus élevés que la valeur des "cadeaux" obtenus avec ces points, qui ne font en fait qu'alourdir la facture).
Il ne s'agit nullement de cryptographie ici: tout y est public.
17 sept. 2003 à 23:04
KUPOOOOOO !!!!
4 sept. 2003 à 19:00
2 sept. 2003 à 11:15