Вт фев 26, 2019 14:05:45
Ср фев 27, 2019 01:30:34
Если же говорить о МК, то лучше сочетать "просто сумму" с контролем четности. Тогда не только всегда выявим двойную ошибку в блоке данных, но и сможем исправить одиночную.
Для примера. Пусть мы передает по последовательному каналу байты. Пусть блок у нас 8 байт. Добавляем к каждому передаваемому байту бит четности и после каждых 8 байт пересылаем сумму (XOR) этих 8 байтов девятым контрольным байтом. Тогда, если ошибка была в одном бите, то не совпадет бит четности в ошибочном байте и один бит в контрольной сумме. То есть, если инвертировать в ошибочном байте тот бит, который не совпал в контрольной сумме - ошибка будет исправлена.
Ср фев 27, 2019 06:06:55
Ср фев 27, 2019 10:08:29
Ср фев 27, 2019 11:39:20
Ср фев 27, 2019 12:44:30
Ср фев 27, 2019 13:27:28
На самом деле, я не понимаю вообще смысла сравнения кодирования с исправлением ошибок и кодирования с расчетом контрольной суммы. В первом случае, при определенной избыточности, Вы всегда данные передадите. Во втором, в общем случае - никогда
Ср фев 27, 2019 13:58:10
Ср фев 27, 2019 14:08:38
Ср фев 27, 2019 16:45:46
Что толку в том, что Вы выявите ошибку, если данные без ошибки Вы не сможете получить?
Условно говоря, мой метод позволяет передавать данные вплоть до вероятности ошибки в 1/4 - матрицей 2х2 на каждый бит.
Ср фев 27, 2019 16:57:21
Ср фев 27, 2019 18:29:35
Ср фев 27, 2019 18:34:40
Ср фев 27, 2019 19:48:27
В итоге, первый алгорит прост, в два раза более устойчив, чем второй, не менее устойчив, чем третий, хоть и проще его на порядок, позволяет корректировать ошибки и легко масштабируется для слов с любым количеством бит (для USART от 5 до 9). Чем он Вам не угодил? Излишней избыточностью? Так это вполне адекватная цена за простоту реализации
Ср фев 27, 2019 22:11:40
Чт фев 28, 2019 00:20:37
Вы серьезно или прикалыаетесь? Если CRC32 еще используется из-за простоты его вычисления, но в тех сферах, где действительно требуется надежность, даже от MD5 уже отказываются в пользу SHA-2. Я уж молчу о банковской сфере, где хеши меньше 1024 бита в принципе даже рассматриваются. И при этом вероятность дублирования хеша все равно существует и вполне ожидаема.
Для примера, всего в конце прошлого года была мной найдена интересная бага. Программист, вместо того, чтобы проверять на уникальность набор из десятка полей по одному, тупо считал SHA-256 хеш по всем ним и сравнивал только его. Это проработало чуть больше года, пока неожиданно не выявилось, что в БД размером в несколько десятков терабайт уже дважды(!) уникальность проверялась некорректно: в БД не попали два сообщения, воспринятые, как уже существующие. Какое там время существования вселенной? )))
Про SHA-1 (160 бит) вообще молчу, так как многие сами сталкивались с тем, что файл скачанный по bittorrent оказывался битым, хотя SHA-1 хеш его совпадал с оригиналом
Чт фев 28, 2019 07:37:25
1024 бита это вообще тема с открытым ключом.
Ошибка в алгоритме где-то. Хватило бы и 128 бит. Возможно он из базы данных брал первые 8 байт и по ним считал SHA, или что-то в этом роде.
пример, примитивный RC-72 до сих пор не взломан
Чт фев 28, 2019 15:19:29
О популярных хэш-алгоритмах
Алгоритмы CRC16/32 — контрольная сумма (не криптографическое преобразование).
Алгоритмы MD2/4/5/6. Являются творением Рона Райвеста, одного из авторов алгоритма RSA.
Алгоритм MD5 имел некогда большую популярность, но первые предпосылки взлома появились еще в конце девяностых, и сейчас его популярность стремительно падает.
Алгоритм MD6 — очень интересный с конструктивной точки зрения алгоритм. Он выдвигался на конкурс SHA-3, но, к сожалению, авторы не успели довести его до кондиции, и в списке кандидатов, прошедших во второй раунд этот алгоритм отсутствует.
Алгоритмы линейки SHA Широко распространенные сейчас алгоритмы. Идет активный переход от SHA-1 к стандартам версии SHA-2. SHA-2 — собирательное название алгоритмов SHA224, SHA256, SHA384 и SHA512. SHA224 и SHA384 являются по сути аналогами SHA256 и SHA512 соответственно, только после расчета свертки часть информации в ней отбрасывается. Использовать их стоит лишь для обеспечения совместимости с оборудованием старых моделей.
Российский стандарт — ГОСТ 34.11-94.
Чт фев 28, 2019 16:08:21
Существующие стандарты CRC-128 (IEEE) и CRC-256 (IEEE) в настоящее время вытеснены криптографическими хеш-функциями.
Сб мар 02, 2019 01:21:10
... Отсутствует Checksum заголовка, соответственно, его не надо проверять, а также пересчитывать для каждого пакета при изменении TTL Hop Limit. Так как checksum больше нет, то вся ответственность за целостность информации должна лежать на протоколе более низкого уровня, так например у Ethernet фреймов есть свой честный CRC32. Так же у UDP пакетов наличие checksum теперь обязательно и UDP/IPv6 пакеты с Checksum 0000 будут просто отбрасываться принимающим хостом;
I agree with you except that the accidental collision rate is higher than 1 in 2^32 or 1 in 2^64 for 32 bit and 64 bit CRCs respectively.
I wrote an app that kept track of things by their CRC values for tracking items. We needed to track potentially millions of items and we started with a CRC32 which in real world practice has a collision rate of around 1 in 2^16 which was an unpleasant surprise. We then re-coded to use a CRC64 which had a real world collision rate of about 1 in 2^23. We tested this after the unpleasant surprise of the 32 bit one we started with and accepted the small error rate of the 64 bit one.