Чому XOR є типовим способом комбінування хешей?

Скажімо , у вас є два хеш H(A)і , H(B)і ви хочете , щоб об'єднати їх. Я читав, що хороший спосіб поєднати два хеши - це XOR, наприклад XOR( H(A), H(B) ).

Найкраще пояснення, яке я знайшов, коротко торкається тут, у цих рекомендаціях щодо хеш-функцій :

XORing двох чисел з приблизно випадковим розподілом призводить до іншого числа, яке все ще має приблизно випадковий розподіл *, але тепер залежить від двох значень.
...
* На кожен біт двох чисел, які потрібно об'єднати, виводиться 0, якщо два біти рівні, інакше a 1. Іншими словами, у 50% комбінацій виведеться 1. Отже, якщо два вхідних біта мають приблизно 50-50 шансів бути 0 або 1, то так само буде і вихідний біт.

Чи можете ви пояснити інтуїцію та / або математику, чому XOR повинен бути операцією за замовчуванням для комбінування хеш-функцій (а не АБО чи І) тощо?

Припускаючи рівномірно випадкові (1-бітні) входи, розподіл ймовірності виходу функції AND становить 75% 0та 25% 1. І навпаки, АБО становить 25% 0і 75% 1.

Функція XOR становить 50% 0і 50% 1, тому вона добре поєднує рівномірні розподіли ймовірностей.

Це можна побачити, виписавши таблиці правди:

 a | b | a AND b
---+---+--------
 0 | 0 |    0
 0 | 1 |    0
 1 | 0 |    0
 1 | 1 |    1

 a | b | a OR b
---+---+--------
 0 | 0 |    0
 0 | 1 |    1
 1 | 0 |    1
 1 | 1 |    1

 a | b | a XOR b
---+---+--------
 0 | 0 |    0
 0 | 1 |    1
 1 | 0 |    1
 1 | 1 |    0

Вправа: Скільки логічних функцій двох 1-бітних входів aі bмають такий рівномірний розподіл виходу? Чому XOR є найбільш підходящим для мети, зазначеної у вашому запитанні?

xor- це небезпечна за замовчуванням функція, яка використовується при хешировании. Це краще, ніж andі or, але це не дуже говорить.

xorсиметричний, тому порядок елементів втрачається. Тож "bad"хеш-комбінат буде таким же, як і "dab".

xor відображає попарно однакові значення до нуля, і вам слід уникати відображення "загальних" значень до нуля:

Отже, (a,a)відображається на 0, а (b,b)також відображається на 0. Оскільки такі пари майже завжди зустрічаються частіше, ніж це може означати випадковість, у вас виникає набагато більше зіткнень у нулі, ніж слід.

З цими двома проблемами, в xorкінцевому підсумку це хеш-комбайнер, який виглядає наполовину пристойно на поверхні, але не після подальшого огляду.

На сучасне обладнання, додавання зазвичай приблизно так само швидко xor(мабуть, мабуть, використовується більше енергії, щоб зняти це, правда,). Додавання таблиці істинності схоже xorна відповідний біт, але воно також надсилає трохи до наступного біта, коли обидва значення дорівнюють 1. Це означає, що він стирає менше інформації.

Так що hash(a) + hash(b)краще, ніж hash(a) xor hash(b)у тому випадку a==b, якщо результат hash(a)<<1замість 0.

Це залишається симетричним; тож "bad"і "dab"отримання однакового результату залишається проблемою. Ми можемо порушити цю симетрію за невелику вартість:

hash(a)<<1 + hash(a) + hash(b)

ака hash(a)*3 + hash(b). ( hash(a)один раз підрахунок і зберігання рекомендується, якщо ви використовуєте рішення зсуву). Будь-яка непарна константа замість 3бієктивно буде відображати " k-бітове" непідписане ціле число до себе, оскільки карта на непідписані цілі числа є математичним модулем 2^kдля деяких k, а будь-яка непарна константа є відносно простою 2^k.

Для рівномірнішої версії ми можемо вивчити boost::hash_combine, що ефективно:

size_t hash_combine( size_t lhs, size_t rhs ) {
  lhs ^= rhs + 0x9e3779b9 + (lhs << 6) + (lhs >> 2);
  return lhs;
}

тут ми додаємо кілька зміщених версій seedз константою (що в основному є випадковими 0s і 1s - зокрема, це обернено золотого відношення як 32-бітна частка з фіксованою точкою) з деяким додаванням і xor. Це порушує симетрію, і вводить деякі «шум» , якщо входять Hashed значення є бідними (тобто, уявіть собі , кожен компонент хеші 0 - вищевказані ручки це добре, створюючи мазок 1і 0. S після кожного помошью наївним 3*hash(a)+hash(b)просто виводить 0ін той випадок).

(Для тих, хто не знайомий з C / C ++, a size_t- ціле цільове значення без підпису, яке є достатньо великим, щоб описати розмір будь-якого об'єкта в пам'яті. У 64-бітовій системі зазвичай це 64-бітове безпідписане ціле число. У 32-бітовій системі , 32-бітове ціле число без підпису.)

Незважаючи на зручні властивості бітового змішування, XOR не є хорошим способом комбінувати хеші завдяки своїй комутативності. Поміркуйте, що буде, якби ви зберегли перестановки {1, 2,…, 10} у хеш-таблиці 10-кортежів.

Значно кращим є вибір m * H(A) + H(B), де m - велике непарне число.

Кредит: Вищезгаданий комбайнер був порадою від Боб Дженкінса.

Xor може бути "за замовчуванням" способом комбінування хешів, але відповідь Грега Х'югілла також показує, чому він має свої підводні камені: xor двох однакових хеш-значень дорівнює нулю. У реальному житті однакові хеші зустрічаються частіше, ніж можна було очікувати. Тоді ви можете виявити, що в цих (не дуже рідкісних) кутових випадках отримані комбіновані хеші завжди однакові (нульові). Зіткнення хешу було б набагато, набагато частішим, ніж ви очікуєте.

У надуманому прикладі ви можете поєднувати хешовані паролі користувачів з різних веб-сайтів, якими ви керуєте. На жаль, велика кількість користувачів повторно використовує свої паролі, і дивовижна частка отриманих хешей дорівнює нулю!

Щось я хочу чітко зазначити для інших, хто знайшов цю сторінку. І та АБО обмежують вихід, як BlueRaja - Danny Pflughoe намагається вказати, але можна краще визначити:

Спершу я хочу визначити дві прості функції, які буду використовувати для пояснення цього: Min () та Max ().

Min (A, B) поверне значення, менше між A і B, наприклад: Min (1, 5) повертає 1.

Max (A, B) поверне значення, яке більше між A і B, наприклад: Max (1, 5) повертає 5.

Якщо вам дано: C = A AND B

Тоді ви можете виявити, що C <= Min(A, B)Ми це знаємо, тому що ви нічого не можете І за допомогою 0 біт A або B зробити їх 1. Отже, кожен нульовий біт залишається нульовим бітом, і кожен бит має шанс стати нульовим бітом (і, таким чином, меншим значенням).

З: C = A OR B

Це навпаки: C >= Max(A, B)з цим ми бачимо наслідки функції AND. Будь-який біт, який вже є одиницею, не може бути ОРЕНДЕНО, тому він залишається одиничним, але кожен нульовий біт має шанс стати одиницею, а значить, більшою кількістю.

Це означає, що стан введення застосовує обмеження на вихід. Якщо у вас І що завгодно з 90, ви знаєте, що вихід буде дорівнює або менше 90, незалежно від іншого значення.

Для XOR не передбачається обмеження на основі вхідних даних. Існують особливі випадки, коли ви можете виявити, що якщо ви XOR байт з 255, ви отримаєте зворотний, але будь-який можливий байт може бути виведений з цього. Кожен біт має шанс змінити стан залежно від того самого біта в іншому операнді.

Якщо ви маєте XORвипадковий вхід з упередженим входом, вихід буде випадковим. Те саме не стосується ANDабо OR. Приклад:

00101001 XOR 00000000 = 00101001
00101001 І 00000000 = 00000000
00101001 АБО 11111111 = 11111111

Як згадує @Greg Hewgill, навіть якщо обидва входи випадкові, використовуючи ANDабо ORпризведе до упередженого виводу.

Причина, яку ми використовуємо XORнад чимось складнішим, полягає в тому, що, ну, немає потреби: XORпрацює прекрасно, і це надзвичайно дурно-швидко.

Накрийте ліві 2 стовпці та спробуйте розробити, які входи використовують лише вихід.

 a | b | a AND b
---+---+--------
 0 | 0 |    0
 0 | 1 |    0
 1 | 0 |    0
 1 | 1 |    1

Коли ви побачили 1 біт, вам слід було б зрозуміти, що обидва входи були 1.

Тепер зробіть те ж саме для XOR

 a | b | a XOR b
---+---+--------
 0 | 0 |    0
 0 | 1 |    1
 1 | 0 |    1
 1 | 1 |    0

XOR нічого не дає про це вхідних даних.

Вихідний код для різних версій hashCode()в java.util.Arrays є чудовим посиланням на тверді алгоритми хешування загального використання. Їх легко зрозуміти і перекласти на інші мови програмування.

Грубо кажучи, більшість реалізацій з декількома атрибутами hashCode()відповідають цій схемі:

public static int hashCode(Object a[]) {
    if (a == null)
        return 0;

    int result = 1;

    for (Object element : a)
        result = 31 * result + (element == null ? 0 : element.hashCode());

    return result;
}

Ви можете шукати інші StackOverflow Q & As для отримання додаткової інформації про магію, що стоїть 31, і чому Java-код використовує її так часто. Він недосконалий, але має дуже хороші загальні експлуатаційні характеристики.

XOR не ігнорує деякі з входів іноді як OR і І .

Якщо ви берете для прикладу AND (X, Y) і подаєте введення X з помилковим, то введення Y не має значення ... і, мабуть, хотілося б, щоб вхід мав значення при поєднанні хешей.

Якщо взяти XOR (X, Y) потім ОБИДВА входи ЗАВЖДИ справа. Там, де Y не має значення, значення X не було б. Якщо змінити або X, або Y, результат буде відображати це.