Thursday, May 15, 2008

הסוף לצווארי בקבוק בטורנטים ?


שלומצ'יק ...

בעקבות שאלה שנשאלה בפורום וואטסאף בנוגע לפריצת bruteforce של סיסמה.
חשבתי למה להדביק את הרעיון על טורנטים ?

כלומר אם יש לנו אפשרות למפות את כל האפשרויות במחרוזת מסויימת הרי שעלמנת להעביר את הקובץ נוכל לשלוח רק hash של המחרוזת (או סתם לעבוד עם חלקים מאוד מאוד קטנים) .


כלומר אם נחלק קובץ לחלקים מספיק קטנים (נגיד 30 ביט) נוכל למעשה לשמור את כל הקובמינציות האפשרויות (2^30 = 1GB המספר הגדול ביותר ) אבל הבעייה תיהיה מקום האחסון -

על מנת לאחסן את כל הקומבינציות האפשרויות ניתן להתייחס לזה כמו לסדרה חשבונית המתחילה מאפס ומכן לקבל :
size = n (An + A1 ) /2 או במילים אחרות 1Pb ( זה יותר מדי) .

אבל מה בנוגע למחרוזות של 20 ביט ? נקבל כבר רק 1 TB של נתונים (בימים אלו זה לא ממש סיפור ) .

כלומר
  1. אם אני מחזיק מספר שרתים שמחזיקים כל אחד 1 טרה בייט של נתונים עבור האפליקציה
  2. אני לוקח קובץ (מספיק פופולארי נגיד דביאן) ומחלק אותו לחלקים קטנים מספיק.
  3. מפיץ את הטורנט הזה.

ומספר משתמשים ירציו את תוכנית שפשוט שופכת קבצים חלקים (נגיד 4 ג"ב) הרי שהמהירות הורדה עבור
___כל הורדה __ תעלה ברגע שאנשים (חדשים) מצטרפים (ואפילו אם הם לא "מבזבזים מקום") לא משנה מה הם מורידים (בן אם זה דביאן , ג'נטו או אפילו אובונטו ;-) ).

כלומר חסר סדר צווארי בקבוק .
חסר סדר הורדה תקועה ב 99.99% של קובץ ISO שבוע (כי מ#@%$@# אחד ברח).
אבל מה ?
איזו מערכת קבצים מאפשרת לי לשמור כמות אינסופית של קבצים כזו (או לפחות מבנה תיקיות כזה)



3 comments:

elcuco said...

מה עם התנגשויות? הרי אתה ממפה מרחב בגודל 2^64 בתים אל 128 בתים זה אומר שכל האש, מתאים לכמה (הרבה מאוד!) צירופים שונים של בתים - לצ'אנקים שונים של מידע.

Jabka Atu said...

אני משתמש בגודל של 30 ביט (כלומר 2^30 ( ואותו אני ממפה -

בגלל שהגודל הוא קבוע ומספיק קטן לא (אמורות ) להיות התנגשויות
הרעיון הוא לא למפות את כל הקובץ אלא חלקים מאוד קטנים ממנו ולאחר מכן להרכיב הכל מחדש .

Anonymous said...

Cut it in small enough parts, and the hashes become larger than the parts. If the hash is not larger than the piece, you need to take care of collisions.

Remember also that for each part you have an overhead of specifying its place in the big file. So, if you cut a 1GB file into 32bit pieces, that's 32M pieces, and for each piece you need at least 27bits just to say which piece it is, not even counting the bits required for the data itself. So you're already passing more than 800M of pure overhead.

Think again, man...