1. घर
  2. सवाल और जवाब
  3. एक आईडी के रूप में sha1 हैश के केवल 64-बिट्स का उपयोग करने के लिए ठीक है?

एक आईडी के रूप में sha1 हैश के केवल 64-बिट्स का उपयोग करने के लिए ठीक है?

2009-04-16 12 views
6

1) वास्तव में कम हैश टकराव के उद्देश्य के लिए, क्या मैं sha1 से निपटने के बजाए sha1 के 128 बिट्स का आधा उपयोग कर सकता हूं? मैं समझता हूं कि यह क्रिप्टोग्राफिक हैंश के लिए उपयुक्त नहीं है, लेकिन मुझे हैश टेबल कुंजी के लिए केवल हैश की आवश्यकता है।एक आईडी के रूप में sha1 हैश के केवल 64-बिट्स का उपयोग करने के लिए ठीक है?

2) गणना समय प्राथमिकता नहीं है, और इसके अतिरिक्त मैं डेटा के बहुत छोटे टुकड़े हैं। विशेष रूप से, मैं ज्यादातर 2 या 3 64-बिट हैश लेने जा रहा हूं और उन्हें 64-बिट हैश प्राप्त करने के लिए परेशान कर रहा हूं। क्या इस उद्देश्य के लिए sha1 से बेहतर विकल्प है? फिर, टकराव बहुत असंभव होना चाहिए।

3) मैं एक एसक्यूएल न्यूबी हूं। एसक्यूएल में आईडी के रूप में 64-बिट हैश का उपयोग करना अच्छा विचार है? 64-बिट आईडी के कारण स्क्लाइट या पोस्टग्रेस में प्रदर्शन समस्याएं होंगी? मुझे कई डेटाबेस (ल्यूसीन इंडेक्स समेत) में डेटा समन्वय करने की आवश्यकता होगी, इसलिए मुझे लगा कि मुझे ऑटो-इंक्रिमेंटेड आईडी के साथ परेशान करने के बजाय सीधे टेबल में हैश से निपटना चाहिए (जो केवल एक डीबी में सार्थक होगा, न कि सभी डेटा स्टोर में)। मुझे लगता है कि 64-बिट एक अच्छा समझौता है: संभावित टक्कर के लिए काफी बड़ा है लेकिन अंतरिक्ष पर बचाता है (और लुकअप समय?)।

4) सीआरसी -64 के बारे में क्या? क्या यह एक यादृच्छिक पर्याप्त वितरण उत्पन्न करता है?

स्रोत

2009-04-16 Jegschemesch

उत्तर

6

यदि आपके पास पर्याप्त रिकॉर्ड हैं तो यह लगभग निश्चित है कि 64 बिट्स में आपके पास कभी हैश टकराव नहीं होगा। शायद आप इस श्रेणी में आ जाएंगे।

वहाँ SHA1 की तरह एक क्रिप्टोग्राफिक हैश छंटाई के साथ कोई समस्या नहीं होनी चाहिए, क्योंकि अगर कोई हैश में आंतरिक संरचना थे तो यह काफी अच्छा एक क्रिप्टो हैश होने के लिए नहीं हो सकता है, और अगर कोई संरचना तो किसी भी है बिट्स का सबसेट काफी यादृच्छिक होना चाहिए। ध्यान दें कि मैं केवल आईडी के लिए इसका उपयोग करने के बारे में बात कर रहा हूं, किसी भी क्रिप्टो उद्देश्यों के लिए नहीं!

लेकिन वास्तव में, क्या आपके एसक्यूएल में कुछ प्रकार का GUID नहीं है? और अगर ऐसा होता है, तो इसका इस्तेमाल क्यों न करें?

स्रोत

2009-04-16 04:04:18 dwc

+0

मुझे लगता है कि GUID/UUID बहुत ज्यादा है जो मैं चाहता हूं। निश्चित नहीं है कि स्क्लाइट समर्थन पर्याप्त है, इसलिए मैं इसकी जांच करूंगा। जैसा कि मैंने कहा, मैं एक एसक्यूएल newb हूँ। – Jegschemesch

+0

एसक्लाइट 3 को आसानी से यूयूआईडी का समर्थन करने के लिए बढ़ाया जा सकता है, और मैंने पहले आईफोन ऐप में सफलतापूर्वक ऐसा किया है। –

+0

मैं इस उत्तर पर सहमत हूं। मेरे पास लाखों पंक्तियों के हंड्रेट से भरा एक टेबल है और प्रदर्शन के कारणों के लिए स्ट्रिंग के रूप में sha1 हैश की बजाय पहले 64 बिट को अनगिनत पूर्णांक कुंजी के रूप में उपयोग करें। 350 मिलियन पंक्तियों के साथ मुझे 56 बिट्स के साथ कुछ टकराव हुए थे। मैं हमेशा 64-बिट-हैश-कुंजी को अपनी तिथि के साथ जोड़ता हूं ताकि दोनों हैशकी और तारीख को मिलान करने की आवश्यकता हो। उस विधि का उपयोग करते हुए मेरे पास केवल 30 मिलियन पंक्तियां होती हैं जो टकराव का कारण बन सकती हैं, जो लंबे समय तक होने का मौका बहुत कम करती है। एक टक्कर से जानकारी की एक शांति को गलत लगेगा - मेरे मामले में बचत के लायक है। – bhelm

0

यदि गणना समय महत्वपूर्ण नहीं है तो क्यों पूरे 128 बिट्स नहीं जाते? क्या संभावित स्टोरेज मुद्दों के बगल में 64 बिट्स चुनने का कोई वास्तविक कारण है? (और फिर अतिरिक्त 8 बाइट आपको स्टोरेज के साथ इतना सस्ता नहीं मारने जा रहे हैं)

64 बिट्स बनाम 128 बिट्स SQLite में कोई गति समस्या नहीं पैदा करेंगे, मैं mySQL के बारे में निश्चित नहीं हूं।

स्रोत

2009-04-16 03:38:36

+0

मुझे लगता है कि यादृच्छिक हैश किए गए डेटा को कुंजी के रूप में उपयोग करते समय, अधिकांश डेटाबेस सिस्टम खोज के साथ अधिक कुशल होते हैं और संचालन में शामिल होते हैं यदि कुंजी तारों के बजाए मशीनों के मूल पूर्णांक में फिट बैठती है। – bhelm

3

आपका कुंजी पूर्ण विशिष्टता की जरूरत नहीं होगी है विशिष्टता की उच्च संभावना। मैं क्रॉस-डेटाबेस संगतता के लिए अपनी चाबियों के लिए हैश के बजाय GUID का उपयोग करने का सुझाव दूंगा। हैश को त्वरित रूप से देखने के तंत्र के रूप में उत्पन्न करें - आपके पास इस पर एक गैर-अद्वितीय अनुक्रमणिका हो सकती है - लेकिन टकराव के मामले में आपको यह सुनिश्चित करने के लिए वास्तविक डेटा की तुलना करनी होगी कि वे वही हैं। अपने डेटाबेस को सिंक्रनाइज़ करने में आप हैश (तुरंत इंडेक्स का उपयोग करके) की जांच कर सकते हैं और यदि आपको टक्कर मिलती है, तो यह हल करें कि डेटा समान है या नहीं, इस प्रकार GUID को हल करने की आवश्यकता है। यदि कोई टक्कर नहीं है, तो बस डेटाबेस को लापता प्रविष्टि की आवश्यकता है और अन्य डेटाबेस से GUID का उपयोग करके सम्मिलित करें।

मैं भी, अंतरिक्ष बचाने के लिए हैश के अपने हैश बनाने में थोड़ा सा बिंदु देखता हूं। यदि आपके पास पहले से ही अन्य हैंश हैं, तो बस उनका उपयोग करें (संलग्न करें, रीहाश न करें)। यदि नहीं, तो बस एक मानक हैश फ़ंक्शन का उपयोग करें जैसे MD5 या SHA1 और परिणामस्वरूप डेटा स्टोर करें।

स्रोत

2009-04-16 03:49:04 tvanfosson

+1

लेकिन मुझे पूर्ण विशिष्टता की आवश्यकता क्यों है? क्या हम बहुत अधिक संभावना के बारे में बात नहीं कर रहे हैं? 1^128 में 1 मौका है कि किसी भी दो वस्तुओं में एक ही हैश है, है ना? क्या हम एक उल्का से मारा जाने के बारे में भी चिंता नहीं कर सकते हैं? या MD5 और sha1 यादृच्छिक रूप से पर्याप्त वितरित नहीं करते हैं? – Jegschemesch

+0

आह, मुझे लगता है कि हम एक-दूसरे से बात कर रहे हैं क्योंकि मैं GUID/UUID की अनजान थी, जबकि आपको लगता था कि मैं नहीं था। लेकिन GUID बिल्कुल अद्वितीय नहीं हैं, है ना? – Jegschemesch

+0

हां। वैश्विक रूप से अद्वितीय (या सार्वभौमिक रूप से अद्वितीय) आईडी बिल्कुल अद्वितीय हैं। पीढ़ी एल्गोरिदम सुनिश्चित करता है कि कोई भी दो मशीनें एक ही आईडी का उत्पादन नहीं करती हैं। मेरा मुद्दा यह था कि यदि आप इसे प्राथमिक कुंजी के रूप में उपयोग कर रहे हैं तो आप एक टकराव भी सहन नहीं कर सकते हैं, चाहे कितना दुर्लभ हो। – tvanfosson

2

64-बिट हैश के साथ, आपके पास 6 के साथ टकराव का 1% मौका है।1 × 10 रिकॉर्ड। (अन्य संयोजनों के लिए, विकिपीडिया के page on the Birthday problem देखें।) आप हर दूसरे बिट के पहले 64-बिट्स या अंतिम को फेंक सकते हैं, इससे हैश के गुणों में कोई फर्क नहीं पड़ता है।

स्रोत

2011-05-25 10:39:09 mjs

संबंधित मुद्दे

 संबंधित मुद्दे