Bits de hachage anti-collision
Stocker 1 000 000 d'éléments avec au plus une chance sur un million de collision demande 59 bits de hachage, la plus petite largeur qui respecte la borne des anniversaires. Vous voyez aussi l'espace de hachage et le risque estimé à cette largeur. Gratuit dans votre navigateur.
- Gratuit
- Fonctionne dans votre navigateur
- Sans inscription
- Vos données restent sur votre appareil
Lancer gratuitement
Exemple résolu
- Éléments
- 1 000 000
- Probabilité maximale
- 0,000001
- Bits nécessaires
- 59
- Probabilité de collision approximative
- 0,0000008674
- Espace de hachage
- 2^59
Lorsque vous choisissez la longueur d'un hachage pour des identifiants, des clés de cache, des digests de contenu ou des codes courts, la question difficile n'est pas seulement de savoir si le digest suffit pour la sécurité de préimage, mais combien d'éléments vous pouvez stocker avant que deux hachages n'entrent en collision par hasard. Ce calculateur résout ce dimensionnement avec la borne classique d'anniversaire. Vous fournissez le nombre attendu d'éléments et la probabilité maximale de collision que vous acceptez ; il renvoie la plus petite largeur entière en bits qui maintient le risque approximatif de collision par paires au plus égal à cette cible, plus la taille de l'espace de hachage et la probabilité approximative à cette largeur.
Borne d'anniversaire et pourquoi la longueur du hachage croît avec le carré de l'ensemble
Un hachage aléatoire uniforme de b bits envoie chaque élément dans un espace de taille deux à la puissance b. Avec un seul élément il n'y a rien avec quoi entrer en collision, mais dès que vous insérez de nombreuses valeurs le nombre de paires non ordonnées croît comme n parmi deux.
Chaque paire entre en collision avec une probabilité d'environ un sur la taille de l'espace, de sorte que le nombre attendu de paires en collision est approximativement n fois n moins un sur deux fois deux à la b. Lorsque cette espérance est petite, elle est aussi une bonne approximation de la probabilité d'au moins une collision. En isolant pour une probabilité cible p on obtient la règle de dimensionnement : bits égale le plafond du logarithme en base deux de n fois n moins un sur deux p.
De façon équivalente, bits vaut environ deux fois le log de n moins le log de p, moins un. Cette structure en racine carrée est le fameux paradoxe des anniversaires en version ingénierie : pour garder les collisions rares avec un milliard d'éléments vous avez besoin de bien plus de trente bits de hachage, et la résistance cryptographique aux collisions face à un adversaire capable d'essayer deux à la soixante-quatre hachages pousse classiquement vers des digests de cent vingt-huit bits ou plus.
Cet outil n'utilise que l'approximation de la borne d'anniversaire —il ne modélise pas les hachages non uniformes, les constructions HMAC tronquées ni les attaques multi-collision au-delà de la paire de base—, traitez donc la réponse comme une borne inférieure de planification pour des digests d'apparence aléatoire, puis ajoutez une marge pour les particularités d'implémentation et les modèles de menace au-delà des collisions de hasard.
Cas d’usage
Planification de la longueur des identifiants et codes courts
Les ingénieurs produit dimensionnent la largeur en bits des hachages tronqués ou des ID aléatoires pour que les collisions attendues parmi les effectifs projetés d'utilisateurs ou d'objets restent sous un budget de risque écrit.
Clés de cache et digests de contenu
Les équipes plateforme choisissent les longueurs de digest pour caches et index de déduplication en parcourant comptes d'éléments et probabilités cibles au lieu de deviner des nombres ronds.
Enseigner la borne d'anniversaire
Formateurs et outils de préparation aux entretiens montrent pourquoi le risque de collision croît avec n au carré et retrouvent de façon déterministe les seuils classiques de soixante-quatre bits en cours.
Questions fréquentes
Quelle formule utilise la borne d'anniversaire ?
La probabilité de collision est approximée par n(n-1)/(2·2^b).
Cela remplace-t-il une revue de sécurité cryptographique ?
Non. Cela ne dimensionne que les collisions de hasard par paires pour des hachages uniformes. Le choix d'algorithme, la troncature, la recherche adversaire de collisions et la force de préimage exigent encore une analyse de sécurité séparée.
Pourquoi les collisions de hachage arrivent-elles plus tôt que prévu ?
Parce que ce sont les paires qui comptent, pas les éléments. Le nombre de paires croît à peu près comme le carré du nombre d'éléments et chaque paire peut entrer en collision : le risque monte donc bien plus vite que la quantité. C'est le paradoxe des anniversaires.
Le résultat vaut-il pour n'importe quelle fonction de hachage ?
Il suppose un hachage uniforme d'apparence aléatoire et la borne de base sur les paires. Il ne modélise ni les hachages inégaux, ni les hachages à clé tronqués, ni les attaques multi-collisions : prenez-le comme un minimum de planification et ajoutez une marge.
Que change le fait de doubler le nombre d'éléments ?
Environ deux bits de plus. Les bits nécessaires valent à peu près deux fois le logarithme en base deux du nombre d'éléments, moins celui de la probabilité visée, moins un : chaque doublement ajoute donc près de deux bits.
Outils associés
Pour les développeurs — accès API
Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.
Endpoint
Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.
Appeler depuis votre stack
curl -X POST https://api.kit.forhosting.com/dev/hash-bits-for-collision \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"items":1000000,"max_probability":0.000001}'const res = await fetch("https://api.kit.forhosting.com/dev/hash-bits-for-collision", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"items": 1000000,
"max_probability": 0.000001
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/hash-bits-for-collision",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"items": 1000000,
"max_probability": 0.000001
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/hash-bits-for-collision", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"items":1000000,"max_probability":0.000001}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"items":1000000,"max_probability":0.000001}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/hash-bits-for-collision", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Exemple de requête
{
"items": 1000000,
"max_probability": 0.000001
}Exemple de réponse
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.hash_bits_for_collision",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.
Tarifs
Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.
Erreurs
| HTTP | Code | Signification |
|---|---|---|
401 | unauthorized | Clé API absente ou invalide : vérifiez l’en-tête Authorization. |
402 | insufficient_balance | Solde insuffisant : rechargez votre compte pour lancer cette tâche. |
404 | unknown_type | Type de tâche inconnu : vérifiez le champ type de votre requête. |
429 | rate_limited | Trop de requêtes : ralentissez la cadence, puis réessayez. |
Notes techniques
La même arithmétique pure s'exécute gratuitement dans le navigateur et comme élément d'API facturé, de sorte que démonstrations pédagogiques, documents de conception et scripts d'automatisation partagent un contrat déterministe sans bruit d'échantillonnage et sans modèle de langage.
Contrat d'entrée, règles de validation et champs de réponse
Exemple : un million d'éléments avec une cible d'un sur un million donne de l'ordre de cinquante-neuf bits et un espace de hachage de deux à cette puissance. Les contrôles classiques de cours tels qu'environ quatre milliards d'éléments à cinquante pour cent de risque retrouvent le chiffre familier de soixante-quatre bits. Envoyez un corps JSON avec deux champs obligatoires. items est un entier positif de un à un quadrillion (un fois dix à la quinze) décrivant combien de valeurs vous prévoyez de hacher ou de stocker ; les alias n, count et num_items sont acceptés. max_probability est un nombre fini strictement entre zéro et un donnant la plus grande probabilité de collision que vous tolérerez sous la borne ; les alias p, probability, target_probability et max_collision_probability fonctionnent de même. Champs manquants, non-entiers pour items, probabilités non finies, comptes nuls ou négatifs, probabilités de zéro ou un ou hors de la plage publiée échouent avec invalid_input et ne sont pas facturés. En succès la réponse renvoie items et max_probability, bits_needed comme la plus petite largeur entière non négative en bits, approximate_collision_probability comme l'estimation de la borne à cette largeur (en utilisant un moins exp de moins lambda lorsque lambda n'est pas minuscule), hash_space comme la chaîne deux circonflexe bits_needed, et une courte chaîne de formule documentant la règle.
Quand utiliser le calculateur, tarification et limites honnêtes du modèle
Utilisez l'outil gratuit du navigateur en concevant des schémas d'identifiants, en choisissant des longueurs de hachage tronqué pour des URL ou des clés de base de données, ou en enseignant pourquoi doubler la taille de l'ensemble coûte environ un bit de plus et non zéro. Le modèle suppose des hachages idéaux uniformes et indépendants et l'approximation standard des paires d'anniversaire ; il ne vous avertira pas des entrées structurées qui brisent l'uniformité, des questions de seconde préimage ou d'extension de longueur, ni d'une recherche adversaire de collisions moins chère que la force brute pour une famille de hachage cassée. Utilisez l'API lorsqu'un pipeline de conception, un assistant de questionnaire de sécurité, un planificateur de capacité ou une plateforme pédagogique a besoin de JSON stable pour de nombreuses paires n et p sous un seul contrat. Chaque requête réussie est un élément facturable à $0.002 ; une validation échouée ne consomme pas de solde. Interprétez toujours bits_needed comme la largeur qu'un digest d'apparence aléatoire doit avoir pour que les collisions de hasard parmi n éléments restent sous p, puis validez séparément l'algorithme réel et la politique de troncature.
Questions techniques
Comment calculer les bits de hachage pour la résistance aux collisions ?
Envoyez des entiers items (ou n) et un max_probability p strictement entre 0 et 1. L'API renvoie bits_needed = ceil(log2(n*(n-1)/(2*p))) sous la borne d'anniversaire, plus la probabilité approximative et hash_space.
Que se passe-t-il si items vaut 1 ?
Avec un seul élément il n'y a pas de paire à faire entrer en collision, donc bits_needed vaut 0 et approximate_collision_probability vaut 0. Les comptes inférieurs à 1 sont rejetés comme invalid_input.
Le calculateur de bits de hachage est-il gratuit ?
L'outil navigateur s'exécute gratuitement sur votre appareil. Les appels API utilisent le solde prépayé KIT à $0.002 par élément réussi ; les échecs de validation ne sont pas facturés.