Есть ли обстоятельства, где хеш-алгоритм может быть гарантирован уникальный?

Вы всегда можете создать собственный хэш, который гарантирует уникальность. Для данных в известном домене (например, SSN) это упражнение относительно простое.

Если у вашего целевого хэш-значения на самом деле больше доступных битов, чем у того, что вы хэшируете, хэш просто сопоставляет входные значения с одним из доступных выходных значений. Это будет простое линейное отображение от входного значения как многобайтового целого к выходному как многобайтовому целому.

Когда целевое хэш-значение имеет меньше битов, чем хэшируемое, уникальность не может быть гарантирована.

Еще в 1997 году я делал это на TI-83 калькуляторах, когда учился в школе и не имел доступа к канальному кабелю.

Обычно в это время вы просто пишете программу сборки, используете TASM для ее построения, а затем переносите ее в калькулятор по кабелю ссылки. Но если мне было скучно и хотелось собрать что-то маленькое вместе, я запомнил достаточно байтовых инструкций, чтобы иметь возможность вводить их для определенных вещей.

Побочное примечание Конечно, это было интересно, если в программе была ошибка, потому что она могла легко повредить всю оперативную память калькулятора. Таким образом, вам придется удерживать кнопку ON и/или удалить батареи AAA и надеяться, что этого будет достаточно, чтобы восстановить calc (sans любые программы, которые были в памяти). В противном случае для жесткого сброса потребуется отвертка, чтобы открутить специальный резервный аккумулятор. Хорошие времена...

Другие ответы, опубликованные до сих пор, сосредоточены на единицах/функциях/производительности/и т.д. тестирование, и все они разумны.

Однако один из ключевых вопросов, который вы должны задать: «Насколько эффективным является мое тестирование?».

На это часто отвечают с помощью инструментов проверки , которые определяют, какие части вашего приложения на самом деле выполняются некоторым набором тестов. Идеальный инструмент проверки покрытия позволяет протестировать приложение любым способом (включая все стандартные ответы выше) и затем сообщить, какая часть и какой процент кода был выполнен. Самое главное, он расскажет вам, какой код вы не использовали . Затем вы можете проверить этот код и принять решение о необходимости дополнительного тестирования или о том, что вам все равно. Если непроверенный код имеет отношение к «полной обработке ошибок диска» и вы считаете, что 1TB диски являются общими, вы можете принять решение игнорировать это. Если непроверенный код является логикой проверки ввода, ведущей к запросам SQL, можно решить, что необходимо протестировать эту логику, чтобы гарантировать отсутствие атак SQL injection.

Какие инструменты тестового покрытия позволяют вам сделать это, чтобы принять рациональное решение, которое вы протестировали адекватно, используя данные о том, какие части вашего кода были выполнены. Таким образом, независимо от того, как вы тестируете, передовые практики указывают на то, что вы также должны выполнять анализ покрытия теста.

Инструменты тестового покрытия могут быть получены из различных источников. SD предоставляет семейство инструментов тестового покрытия , которые обрабатывают C, C++, Java, C #, PHP и COBOL, все из которых используются для поддержки тестирования веб-сайта различными способами.

Вероятность хеш-коллизии не имеет ничего общего с размером входной последовательности (за исключением того, что она указывает на то, сколько входных данных необходимо сохранить уникальность). Существует возможность возникновения хеш-коллизии при хешировании 0 и 1 с использованием идеального алгоритма хеширования, хотя эта возможность равна 1/( 2 ^ bit-length). Что в случае SHA-256 фактически равно нулю.

Хеш-коллизии являются проблемой парадокса дня рождения. В случае 256-битового хешавероятность коллизии между двумя входами зависит исключительно от количества входов и составляет:

• 1 - (2 ^ 256) !/( (2 ^ 256 ^ inputcount) * (2 ^ 256-inputcount)!) или, как говорили другие - в основном ноль для разумного количества входов.

Другие отмечали, что коллизии не должны вызывать беспокойства; в этом весь смысл криптографически безопасных хэш-функций.Я просто хотел бы добавить следующее:

• Если ваш входной набор достаточно мал (например, данные - это SSN - их меньше миллиарда), то отсутствие коллизий поддается проверке: просто проверьте его исчерпывающе. .
• Если набор входных данных слишком велик для полного сканирования, то ожидается, что отсутствие коллизии не может быть доказано . Ожидается, что хорошие хэш-функции будут действовать как случайные оракулы, а на случайном оракуле вы не можете доказать такое свойство, не пытаясь исчерпывающе. Возможность доказать отсутствие столкновения подозрительно выглядела бы слабым местом функции.

Если вы используете криптографический хеш, например SHA, краткий ответ - да.

Одной из ключевых особенностей криптографически безопасной хэш-функции является то, что вы защищены от конфликтов вне всяких разумных сомнений, независимо от входных данных. Это также справедливо для ввода короче, чем размер вывода, что аналогично более длинному сообщению с небольшой энтропией. Таким образом, вы можете использовать SHA-2, не беспокоясь о коллизиях.