Проверка возможности взлома приватного блокчейна
Предлагаю вознаграждение тому, кто опишет способ взлома приватного блокчейна.
Условия следующее:
Есть база данных. Пусть это будет типовая БП. Есть один владелец базы. У него есть полный доступ к базе и возможность делать любые транзакции. Владелец базы хочет, чтобы его действия стали прозрачными для некоторого контрагента, который является его поставщиком, и которого мы дальше будем называть проверяющим. С этой целью он создает журнал на основе блокчейна. Журнал содержит ИД документа, хэш документа, хэш начальный и хэш конечный. Владелец базы дает проверяющему доступ на чтение к базе и доступ на чтение к журналу. Проверяющий создает сам или получает от Владельца программу проверки. Как именно - не важно, потому что, в любом случае код проверяющей программы открыт и находится под контролем Проверяющего. Эта программа запускается регулярно и проверяет соотвествие хэш-сумм и содержимого документов, соотвествие начальных и конечных ключей, и, наконец, соотвествие последнего ключа предыдущей проверки этому же ключу для текущей проверки. Т.е. провели проверку журнала. Последний блок Х содержал ключ Y. Через некоторое время проводим проверку снова и проверяем, чтобы конечный ключ блока Х был равен Y.
Прозрачность заключается в том, что Проверяющий после каждой проверки будет получать список новых документов. И может быть уверен, что никакие старые документы не менялись и не удалялись.
Для получения вознаграждения требуется описать последовательность действий Владельца с базой и с журналом, которая приведет к тому, что эти действия будут скрыты от Проверяющего. Требуется привести доказательства того, что сам факт этих действий не будет зарегистрирован проверяющей программой.
Срок проведения данного конкурса - до 10.08.2019.
Условия следующее:
Есть база данных. Пусть это будет типовая БП. Есть один владелец базы. У него есть полный доступ к базе и возможность делать любые транзакции. Владелец базы хочет, чтобы его действия стали прозрачными для некоторого контрагента, который является его поставщиком, и которого мы дальше будем называть проверяющим. С этой целью он создает журнал на основе блокчейна. Журнал содержит ИД документа, хэш документа, хэш начальный и хэш конечный. Владелец базы дает проверяющему доступ на чтение к базе и доступ на чтение к журналу. Проверяющий создает сам или получает от Владельца программу проверки. Как именно - не важно, потому что, в любом случае код проверяющей программы открыт и находится под контролем Проверяющего. Эта программа запускается регулярно и проверяет соотвествие хэш-сумм и содержимого документов, соотвествие начальных и конечных ключей, и, наконец, соотвествие последнего ключа предыдущей проверки этому же ключу для текущей проверки. Т.е. провели проверку журнала. Последний блок Х содержал ключ Y. Через некоторое время проводим проверку снова и проверяем, чтобы конечный ключ блока Х был равен Y.
Прозрачность заключается в том, что Проверяющий после каждой проверки будет получать список новых документов. И может быть уверен, что никакие старые документы не менялись и не удалялись.
Для получения вознаграждения требуется описать последовательность действий Владельца с базой и с журналом, которая приведет к тому, что эти действия будут скрыты от Проверяющего. Требуется привести доказательства того, что сам факт этих действий не будет зарегистрирован проверяющей программой.
Срок проведения данного конкурса - до 10.08.2019.
Найденные решения
(282)
Например мне удалось найти коллизию и я поменял контрагента и адрес, так что бы в сумме хеш по алгоритму не изменился. Вы будете видеть все тот же документ, но с отличными данными, ключи совпадут. Если ваш хеш алгоритм уникален для любого состава данных, то это по сути версионирование, снимок последнего состояния. Это уже не совсем хеш.
Как поможет соль - просто нереально будет определить алгоритм хеширования по хеш-таблице, точнее, цена поиска будет стремиться к безконечности и будет не выгодна.
Например мне удалось найти коллизию и я поменял контрагента и адрес, так что бы в сумме хеш по алгоритму не изменился. Вы будете видеть все тот же документ, но с отличными данными, ключи совпадут. Если ваш хеш алгоритм уникален для любого состава данных, то это по сути версионирование, снимок последнего состояния. Это уже не совсем хеш.
Как поможет соль - просто нереально будет определить алгоритм хеширования по хеш-таблице, точнее, цена поиска будет стремиться к безконечности и будет не выгодна.
(1) ручная операция сторно документов ( или просто ручные операции) , позволит изменить движения документов ( хотя и текущим числом ) для проверочной программы это будет как новый документ , и по сути основной документ не меняется и хеши будут сходится ( ведь движения меняем в другим документом ) но данные для базы будут изменены можно например полностью сторнировать движения документов.
(1) кто помешает
1. переименовать Поставщика и получателя и получить те же документы с другими контрагентами? В Журналах(документах) только ссылки на справочники. Сами данные справочников в журнале не сохраняются.
2. обработкой поменять записи в регистрах не затрагивая сами документы. Журнал данные регистра не хранит.
1. переименовать Поставщика и получателя и получить те же документы с другими контрагентами? В Журналах(документах) только ссылки на справочники. Сами данные справочников в журнале не сохраняются.
2. обработкой поменять записи в регистрах не затрагивая сами документы. Журнал данные регистра не хранит.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(316)
То что ценно для меня может ничего не значить для миллионов других людей. Мы же не можем ориентироваться в таком вопросе на моё или ваше мнение о ценности той или иной статьи.
Потому что такое восприятие зависит от настроения, образования, окружающей среды, воспитания и тд. И мы дойдём до "сколько людей столько и мнений".
Хотя многие предпочтения нейробиологи всё же могут объяснить.
А вы отвечайте, исходя из того, что ВЫ понимаете под ценностью.
То что ценно для меня может ничего не значить для миллионов других людей. Мы же не можем ориентироваться в таком вопросе на моё или ваше мнение о ценности той или иной статьи.
Потому что такое восприятие зависит от настроения, образования, окружающей среды, воспитания и тд. И мы дойдём до "сколько людей столько и мнений".
Хотя многие предпочтения нейробиологи всё же могут объяснить.
(325)
Михаил что вам не понятно из написанного?
Пишу вроде русским языком, чёрными буквами по белому фону. В чём сложность?
Есть плюсы и минусы, есть полезность статьи. Плюсы и минусы в моём понимании это отношение их поставивших к материалу, подаче или автору("Увидел статью username ставь плюс не глядя", "Плюсанул автора не глядя" и тд вы же видели такие комментарии?) Так это ценность или отношение?
Или этот факт проходит мимо вашего внимания?
Михаил что вам не понятно из написанного?
Пишу вроде русским языком, чёрными буквами по белому фону. В чём сложность?
Есть плюсы и минусы, есть полезность статьи. Плюсы и минусы в моём понимании это отношение их поставивших к материалу, подаче или автору("Увидел статью username ставь плюс не глядя", "Плюсанул автора не глядя" и тд вы же видели такие комментарии?) Так это ценность или отношение?
(327)
Почему нет? Есть авторы которым минусы ставят даже не читая их статей. Или вы считаете что тот кто поставил плюс или минус прочитал всё от начала до конца, потом подумал, оценил и принял решение? Я так думаю половина оценок выставляется на эмоциях и те кто их ставит принимают решение об этом не прочитав и 1/3 статьи.
Интересная задача прогнозирование отклика на статью :)
А "минусанул" не глядя бывает?
Почему нет? Есть авторы которым минусы ставят даже не читая их статей. Или вы считаете что тот кто поставил плюс или минус прочитал всё от начала до конца, потом подумал, оценил и принял решение? Я так думаю половина оценок выставляется на эмоциях и те кто их ставит принимают решение об этом не прочитав и 1/3 статьи.
Интересная задача прогнозирование отклика на статью :)
(332)Не знаю, надо проверять. Но проверить это можно только зная сколько тот или иной пользователь провёл за чтением статьи.
Ну и плюсы ставят чаще чем минусы. Есть ещё момент, плюсы в статьях на сколько знаю может ставить "любой", а минусы "не только лишь все" а те у кого рейтинг более 30.
Ну и плюсы ставят чаще чем минусы. Есть ещё момент, плюсы в статьях на сколько знаю может ставить "любой", а минусы "не только лишь все" а те у кого рейтинг более 30.
(333) Я не зря обращаю внимание на "не глядя".
Допустим в статье ничего нет. Ни новой информации, ни какого-нибудь неожиданного взгляда на известные проблемы, ни даже какого-нибудь простенького лайфхака. Но есть забавные картинки и несколько более или менее удачных шуток.
С какой вероятностью такая статья соберет плюсы? С какой вероятностью она соберет минусы?
Другая статья выдвигает очень неожиданные и спорные тезисы. Кому-то нравится свежая мысль. Кто-то категорически несогласен. Но равнодушных практически нет.
Что будет с этой статьей в плане плюсов и минусов?
Допустим в статье ничего нет. Ни новой информации, ни какого-нибудь неожиданного взгляда на известные проблемы, ни даже какого-нибудь простенького лайфхака. Но есть забавные картинки и несколько более или менее удачных шуток.
С какой вероятностью такая статья соберет плюсы? С какой вероятностью она соберет минусы?
Другая статья выдвигает очень неожиданные и спорные тезисы. Кому-то нравится свежая мысль. Кто-то категорически несогласен. Но равнодушных практически нет.
Что будет с этой статьей в плане плюсов и минусов?
(275)Если У Вас есть ограниченное количество данных версионирование которых Вы ведете, то конечно же работать будет, но это единичная реализация, на никакую уникальность не претендующая. Это все равно, что утверждать, что в крестики нолики всегда будет ничья. Но если оба понимают правила игры.
Я не понимаю, логику ошибок чего мы ищем. Того что если знать конечный массив данных и регистрировать факт изменений с помощью регистрации изменений хеш сумм? Конечно, если алгоритм расчета хеша не будет содержать ошибок, что при разных значениях формируется одинаковый хеш, то ошибок не будет.
О ключах, на основании чего формируется ключ Х. Укажите формулу.
Я не понимаю, логику ошибок чего мы ищем. Того что если знать конечный массив данных и регистрировать факт изменений с помощью регистрации изменений хеш сумм? Конечно, если алгоритм расчета хеша не будет содержать ошибок, что при разных значениях формируется одинаковый хеш, то ошибок не будет.
О ключах, на основании чего формируется ключ Х. Укажите формулу.
(281) Но как можно использовать коллизии для бух документов? У вас есть изначальный документ и его хэш.
Допустим вам удалось найти коллизию для этого хэша. Какова вероятность того, что используя эту коллизию, вы получите бух документ?
И каким образом криптосоль может решить эту гипотетическую проблему?
Допустим вам удалось найти коллизию для этого хэша. Какова вероятность того, что используя эту коллизию, вы получите бух документ?
И каким образом криптосоль может решить эту гипотетическую проблему?
(282)
Например мне удалось найти коллизию и я поменял контрагента и адрес, так что бы в сумме хеш по алгоритму не изменился. Вы будете видеть все тот же документ, но с отличными данными, ключи совпадут. Если ваш хеш алгоритм уникален для любого состава данных, то это по сути версионирование, снимок последнего состояния. Это уже не совсем хеш.
Как поможет соль - просто нереально будет определить алгоритм хеширования по хеш-таблице, точнее, цена поиска будет стремиться к безконечности и будет не выгодна.
Например мне удалось найти коллизию и я поменял контрагента и адрес, так что бы в сумме хеш по алгоритму не изменился. Вы будете видеть все тот же документ, но с отличными данными, ключи совпадут. Если ваш хеш алгоритм уникален для любого состава данных, то это по сути версионирование, снимок последнего состояния. Это уже не совсем хеш.
Как поможет соль - просто нереально будет определить алгоритм хеширования по хеш-таблице, точнее, цена поиска будет стремиться к безконечности и будет не выгодна.
(294) Мне кажется, что все гораздо проще. Используем общеизвестный алгоритм, например SHA256 или двойную SHA256.
Какова, для начала, цена поиска коллизии для конкретного хэша? Как вы ее будете искать?
Вот у вас есть товар, количество, цена. Будете перебирать все возможные варианты? Какова вероятность, того что такую коллизию вообще невозможно подобрать? Т.е. коллизии есть, но ни одна из них не может содержать названия какого-либо товара.
Какова, для начала, цена поиска коллизии для конкретного хэша? Как вы ее будете искать?
Вот у вас есть товар, количество, цена. Будете перебирать все возможные варианты? Какова вероятность, того что такую коллизию вообще невозможно подобрать? Т.е. коллизии есть, но ни одна из них не может содержать названия какого-либо товара.
(296)Абсолютно не важно sha 256 или, что-то еще. В мире хакеров, если есть исходные данные и зашифрованные, а также осутствует погрешность(соль), то получить обратным преобразованием алгоритм возможно. Зная колизии алгоритма можно подменить данные.
Испортить данные это ведь тоже изменить документ не так ли.
Еще раз, я не понимаю. Мы доказываем, что это ВОЗМОЖНО. Или что это МАЛОВЕРОЯТНО?
Алгоритм действий. Берем таблицы документов с наборами данных, берем хеш. Берем или пишем анализатор, который проверяет на стандартные алгоритмы, подбираем преобразования, что бы получить данный хеш, находим алгоритм. Меняем данные так, что бы хеш не изменился. Даже если в данных станет ахинея, все равно это выполняет условия задачи.
Испортить данные это ведь тоже изменить документ не так ли.
Еще раз, я не понимаю. Мы доказываем, что это ВОЗМОЖНО. Или что это МАЛОВЕРОЯТНО?
Алгоритм действий. Берем таблицы документов с наборами данных, берем хеш. Берем или пишем анализатор, который проверяет на стандартные алгоритмы, подбираем преобразования, что бы получить данный хеш, находим алгоритм. Меняем данные так, что бы хеш не изменился. Даже если в данных станет ахинея, все равно это выполняет условия задачи.
(297) Подберите коллизию SHA256 к следующей строке:
20135;Сахар-песок пакет 0,9 кг;112;78
Учтите, что в коллизии обязательно должны быть три символа ";".
Подумайте над этим и вы поймете, что:
1) для поиска вам придется перебрать количество вариантов, сравнимое с количеством атомов во всей вселенной
2) не факт, что такая коллизия вообще существует
20135;Сахар-песок пакет 0,9 кг;112;78
Учтите, что в коллизии обязательно должны быть три символа ";".
Подумайте над этим и вы поймете, что:
1) для поиска вам придется перебрать количество вариантов, сравнимое с количеством атомов во всей вселенной
2) не факт, что такая коллизия вообще существует
(299)
Стоп, за подбор я бы запросил 200тыс $.
Мы говорим ВОЗМОЖНО ЛИ ЭТО?
Теоретически ? - да. Сложно ли ?- да.
Поможет Вам такой подход - да. Об этом я уже много говорил. Но и говорил, что бы покрыть возможность обмануть - этого мало. Так как отчеты строятся не на документах. Да и возможности повлиять на БД, даже если вы хеш пишите тригерами - обширна.
Зачем я тратил время.
20135;Сахар-песок пакет 0,9 кг;112;78
Стоп, за подбор я бы запросил 200тыс $.
Мы говорим ВОЗМОЖНО ЛИ ЭТО?
Теоретически ? - да. Сложно ли ?- да.
Поможет Вам такой подход - да. Об этом я уже много говорил. Но и говорил, что бы покрыть возможность обмануть - этого мало. Так как отчеты строятся не на документах. Да и возможности повлиять на БД, даже если вы хеш пишите тригерами - обширна.
Зачем я тратил время.
(351) Вы напрасно с такой легкостью говорите: возможно. Это требует доказательств.
Это хорошо, что вы знаете цену подбора. А вы бы согласились бы на условие, что если вы не подберете за месяц, тогда вы платите 200 тыс.? Подумайте над этим.
А в этом и смысл блокчейна. Несмотря на то, что вы можете делать с базой все, что хотите, все ваши действия прозрачны для проверяющего.
Это хорошо, что вы знаете цену подбора. А вы бы согласились бы на условие, что если вы не подберете за месяц, тогда вы платите 200 тыс.? Подумайте над этим.
А в этом и смысл блокчейна. Несмотря на то, что вы можете делать с базой все, что хотите, все ваши действия прозрачны для проверяющего.
(353)ОФФТОП. Но думаю, да. За 200тыс долларов предоплаты я бы помог Питеру Тоду найти ребят :-).
По теме - я математик, если коллизии существуют, то можно найти. Остальное вопрос техники, алгоритмов, вычислительных мощностей. За такую сумму можно построить огромную бот ферму брутфорсеров. и приблишение в 2^128 не такое и огромное число поиска. Но дискусия не о том.
По теме - я математик, если коллизии существуют, то можно найти. Остальное вопрос техники, алгоритмов, вычислительных мощностей. За такую сумму можно построить огромную бот ферму брутфорсеров. и приблишение в 2^128 не такое и огромное число поиска. Но дискусия не о том.
Автор сам только на половину понимает, что пишет.
В данном случаи что бы проверяющему определить была или не была изменена база нужно иметь свою копию базы целиком или частично. А проверка делается путем сверки своей копии с оригиналом. Если своей копии у проверяющего не будет, то сверять не с чем, база может за ночь полностью смениться и все цепочки хешей будут сходиться, нужно проверяющему иметь хотя бы 1 последний хэш документа базы.
Тот же самый способ проверки организуется обычным копированием базы проверяющим.
Наличие хеша документа в базе, дает возможно копировать проверяющему не все документы целиком, а только их хеши, т.е. меньший объем информации.
Наличие цепочки хешей, дает возможность копировать проверяющему не все хеши всех документов, а только определенную долю. Таким образом для последующей сверки проверяющим базы на предмет ее изменения, достаточно иногда копировать хеши некоторых свежих документов.
Такая система обеспечивает только одностороннее доверие проверяющего к базе. А доверия к оценке проверяющего третьей стороной нет. Проверяющий может сказать, что база изменена, потому что его частичная копия не сходится с базой. Что бы разрешить этот конфликт, 3 сторона тоже должна иметь частичную копию базы, при чем с момента раньше конфликта между базой и проверяющим.
В данном случаи что бы проверяющему определить была или не была изменена база нужно иметь свою копию базы целиком или частично. А проверка делается путем сверки своей копии с оригиналом. Если своей копии у проверяющего не будет, то сверять не с чем, база может за ночь полностью смениться и все цепочки хешей будут сходиться, нужно проверяющему иметь хотя бы 1 последний хэш документа базы.
Тот же самый способ проверки организуется обычным копированием базы проверяющим.
Наличие хеша документа в базе, дает возможно копировать проверяющему не все документы целиком, а только их хеши, т.е. меньший объем информации.
Наличие цепочки хешей, дает возможность копировать проверяющему не все хеши всех документов, а только определенную долю. Таким образом для последующей сверки проверяющим базы на предмет ее изменения, достаточно иногда копировать хеши некоторых свежих документов.
Такая система обеспечивает только одностороннее доверие проверяющего к базе. А доверия к оценке проверяющего третьей стороной нет. Проверяющий может сказать, что база изменена, потому что его частичная копия не сходится с базой. Что бы разрешить этот конфликт, 3 сторона тоже должна иметь частичную копию базы, при чем с момента раньше конфликта между базой и проверяющим.
(340) Про последний хэш в условии сказано. Проверяющий имеет доступ на чтение к базе и журналу. Проверяющий не хранит у себя ничего, кроме последнего хэша. Этого достаточно для того, чтобы контролировать изменения.
Вы понимаете разницу между сверкой двух баз и проверкой журнала?
Третий лишний)))
Вы понимаете разницу между сверкой двух баз и проверкой журнала?
Третий лишний)))
(341) Если не будет своей копии, то сравнивать не с чем. Админ по собственным желаниям или по велению начальства, может заменить базу целиком и пересчитать все цепочки хешей, что бы алгоритм проверки показывал, что никто документы не изменял.
А третьей стороной всегда может быть суд, внутренняя проверка компании, новый собственник компании.
А третьей стороной всегда может быть суд, внутренняя проверка компании, новый собственник компании.
(372) Я про это и писал. Хэш последнего блока и является контрольной суммой для всех контролируемых документов(частичная копия базы) и его надо хранить у себя.
А вот хранение копии базы целиком, как раз дает 100% гарантию при сравнении, что базу изменяли или нет. А хранение последнего хеша дает гарантию 99% или очень близкую к 100%, потому что существуют коллизии для хеша.
Еще есть проблема, если не делалась копия базы или последнего хэша, например, 2 дня. То эти последние 2 дня, база может меняться, как угодно, без отслеживания этого события проверяющим.
И админ может базу целиком заменить. А потом с последним хэшем, ни кому не докажешь, что ты прав. Доказательством будет только документ с печатью.
А "красивые" хэши и распределенные базы для того и нужны, что бы админы за ночь не могли пересчитать все хэши и тогда даже последний хэш хранить не обязательно.
А вот хранение копии базы целиком, как раз дает 100% гарантию при сравнении, что базу изменяли или нет. А хранение последнего хеша дает гарантию 99% или очень близкую к 100%, потому что существуют коллизии для хеша.
Еще есть проблема, если не делалась копия базы или последнего хэша, например, 2 дня. То эти последние 2 дня, база может меняться, как угодно, без отслеживания этого события проверяющим.
И админ может базу целиком заменить. А потом с последним хэшем, ни кому не докажешь, что ты прав. Доказательством будет только документ с печатью.
А "красивые" хэши и распределенные базы для того и нужны, что бы админы за ночь не могли пересчитать все хэши и тогда даже последний хэш хранить не обязательно.
(373) Про распределенные базы мы не говорим. У нас блокчейн - приватный. О коллизиях я уже подробно написал в (368). Насчет коллизий вы неправы. А также вы неправы в том, что полная копия базы дает 100% гарантию.
100% гарантию дает блокчейн, а полная копия в общем случае дает 0%.
100% гарантию дает блокчейн, а полная копия в общем случае дает 0%.
(374) Что это за бред, копия дает гарантию 0%? Смысл слова копия - это полное воспроизведение базы данных. Если нет этого воспроизведения, то и нет копии.
Такое ощущение, что ботом разговариваешь, который только на ключевые слова реагирует, не вникая в смысл текста.
Такое ощущение, что ботом разговариваешь, который только на ключевые слова реагирует, не вникая в смысл текста.
(372)
А как будет работать вся эта схема в такой ситуации:
Мы обменялись документами, посчитали хэш. Я же правильно понимаю что мне нужно хранить только последний хэш?
Что будет если вы исправляете какой то документ в прошлом месяце например? Вы это делаете в вашей базе. Я проверяю хэш который хранится у меня и он не совпадает?
Вместо копии базы достаточно хранить один хэш. Этого достаточно для того, чтобы обнаружить любое изменение.
А как будет работать вся эта схема в такой ситуации:
Мы обменялись документами, посчитали хэш. Я же правильно понимаю что мне нужно хранить только последний хэш?
Что будет если вы исправляете какой то документ в прошлом месяце например? Вы это делаете в вашей базе. Я проверяю хэш который хранится у меня и он не совпадает?
(385)
Вот это.
Ещё раз.
Вы что то переделали в прошлом периоде, не с целью что то подделать, а например исправили какие то документы. Ваш новый хэш с моим контрольным не сойдутся?
Что тут непонятного?
Вот это.
Если вы видите, что хэш не сходится, вы перестаете доверять.
Хэши всегда сходятся.
Ещё раз.
Вы что то переделали в прошлом периоде, не с целью что то подделать, а например исправили какие то документы. Ваш новый хэш с моим контрольным не сойдутся?
(386) У вас есть два способа.
Первый. Вы никогда не исправляете старые документы. Если надо изменить что-то, вы вводите новый документ. Как понимаете, в этом случае хэши всегда сходятся.
Второй, более привычный для 1С. Вы исправляете старый документ. Старый блок в журнале помечается, как исправленный. В конец журнала добавляется новый блок. У старого блока хэш не соответствует данным документа, но мы его и не проверяем. Мы проверяем новый блок. У нового блока хэш и данные сходятся.
Способы разные, результат один - все изменения "всплывают".
Первый. Вы никогда не исправляете старые документы. Если надо изменить что-то, вы вводите новый документ. Как понимаете, в этом случае хэши всегда сходятся.
Второй, более привычный для 1С. Вы исправляете старый документ. Старый блок в журнале помечается, как исправленный. В конец журнала добавляется новый блок. У старого блока хэш не соответствует данным документа, но мы его и не проверяем. Мы проверяем новый блок. У нового блока хэш и данные сходятся.
Способы разные, результат один - все изменения "всплывают".
(388)
Я понял что изменения "всплывут", вопрос в другом, всплыли изменения, как вы будете возвращать доверие? Я же должен доверять вашей системе и при этом хранить только последний хэш.
Пришёл утром на работу, хэши не сошлись. Вы мне говорите что вы что то исправили. Теперь контрольный хэш новый. Но у меня есть только старый хэш с помощью которого я проверить не могу и новый который я как то должен проверить. Или нет?
В общем суть вопроса в возврате доверия если хэши не сошлись. Вы меня не обманывали, а именно исправили ошибку в вашей базе, логично хэши не сходятся. Как будем работать дальше?
Способы разные, результат один - все изменения "всплывают".
Я понял что изменения "всплывут", вопрос в другом, всплыли изменения, как вы будете возвращать доверие? Я же должен доверять вашей системе и при этом хранить только последний хэш.
Пришёл утром на работу, хэши не сошлись. Вы мне говорите что вы что то исправили. Теперь контрольный хэш новый. Но у меня есть только старый хэш с помощью которого я проверить не могу и новый который я как то должен проверить. Или нет?
В общем суть вопроса в возврате доверия если хэши не сошлись. Вы меня не обманывали, а именно исправили ошибку в вашей базе, логично хэши не сходятся. Как будем работать дальше?
(394)Так вот у меня и вопрос. Если я храню один хэш, вы меняете что то у себя в базе, этот один хэш то же изменится. Я сверяю свой с вашим, вы мне говорите что вы изменяли документы задним числом из за ошибки.
Что мне нужно сделать что бы после этого вновь "доверять" вашему хэшу? Пересчитать весь журнал?
Что мне нужно сделать что бы после этого вновь "доверять" вашему хэшу? Пересчитать весь журнал?
(343) И как он проверит начальный хеш , если сам документ удален и внесенные остатки ручными операциями + часть документов будет помечена на удаления которые не смогут удалится .т.е. хеши оставшихся документов изменятся если стоит проверка на пометку на удаления , а какя понимаю она у вас проверяется
(345) Стоп вот пример цепочки
Документ1 - Документ2 - тут произошла Свертка базы - Документ3
Вроде предыдущие документы есть - значит должен быть начальный хэш , Если вы предлагаете обрезать журнал и начинать с нового блока - то можно спокойной изменить старый денные не боясь их обнаружения
Документ1 - Документ2 - тут произошла Свертка базы - Документ3
Вроде предыдущие документы есть - значит должен быть начальный хэш , Если вы предлагаете обрезать журнал и начинать с нового блока - то можно спокойной изменить старый денные не боясь их обнаружения
(347) Свертка происходит с помощью ручных операций , Сам факт "обрезания" журнал говорит о том что можно изменять данные - и как проверяющий будет доказывать что вы не изменили данные перед сверткой , имея на руках последний хэш ?
т.е. Алгоритм таков - меняете документы проверяющего - делаете свертку базы - производите удаление помеченных объектов. Для проверяющего говорите что копий баз нет
т.е. Алгоритм таков - меняете документы проверяющего - делаете свертку базы - производите удаление помеченных объектов. Для проверяющего говорите что копий баз нет
(350)А зачем удалять из журнала документ. Была же ссылка и хеш. Не стало документа, значит, что то изменилось и доверять данным нельзя. В темболее понятно какие документы изменились. Я так понял здесь вопрос, можно ли говорить, что данные не изменились, если хеш документов не менялся. Можно ли доверяться такой технологии. Автор еще упомянул, что он рассматривает, даже не документы а абстрактные наборы данных в документах. Речи нет ни о движении, ни о отчетах. Вся эта реализация - чистая теория, и как конь в вакууме - частный случай.
(350) Я недостаточно точно выразился. Я хотел сказать, что вы можете переписать историю Куликовской битвы и проверяющий этого не заметит. Из контекста это должно было быть понятно.
Еще раз. Нет никаких документов. Их удалили. Все. Что вы там поменяли или поменяете уже никого не волнует. Есть один новый документ "Ввод начальных остатков". И этот документ контролируется обычным образом. Проверяющий его видит. На этом все. Мы не обсуждаем содержание документов. Мы обсуждаем их прозрачность.
Вы говорите: владелец впишет в документ начальных остатков миллион. Ну и что? Он может и не в документ начальных остатков это написать, а, например, в документ "Списание безналичных денежных средств" или в документ "Возврат товаров". Какая разница? Мы же сразу договорились, что владелец может написать все, что хочет. Наша задача - увидеть все, что он напишет.
Еще раз. Нет никаких документов. Их удалили. Все. Что вы там поменяли или поменяете уже никого не волнует. Есть один новый документ "Ввод начальных остатков". И этот документ контролируется обычным образом. Проверяющий его видит. На этом все. Мы не обсуждаем содержание документов. Мы обсуждаем их прозрачность.
Вы говорите: владелец впишет в документ начальных остатков миллион. Ну и что? Он может и не в документ начальных остатков это написать, а, например, в документ "Списание безналичных денежных средств" или в документ "Возврат товаров". Какая разница? Мы же сразу договорились, что владелец может написать все, что хочет. Наша задача - увидеть все, что он напишет.
Подведу итоги конкурса.
Несмотря на то, что схему взлома никто не нашел, конкурс получился очень продуктивным.
В попытках найти схему взлома были выявлены несколько важных ньюансов.
1. VADIM1011985 практически сходу предложил менять движения документов, не трогая сами документы. Сама эта идея, что называется, лежит на поверхности. И полтора года назад, когда была представлена первая экспериментальная реализация приватного блокчейна, я ее конечно же учитывал. Но тогда я остановился на том, что документ можно представлять расширено. Добавляем к реквизитам и табличным частям еще и движения документа. Просто рассматриваем движения, как дополнительные табличные части и вопрос закрыт. Здесь скрыта одна неочевидная проблема, которая проявилась в результате обсуждения. Почему, собственно, я и считаю, что указавший на нее достоин вознаграждения, хоть это и не схема взлома.
Не секрет, что типовые конфигурации избыточны, если не сказать больше. Подключение приватного блокчейна к типовой конфигурации, очевидно, потребует действий по настройке такого подключения. В экспериментальной реализации приватного блокчейна, которую я представлял здесь полтора года назад, пользователю предлагалось расширенное представление документа. Кроме реквизитов и табличных частей, в такое представление входили движения документа. Можно было сказать, что есть обычные табличные части, а есть табличные части движений. Такой подход, действительно таит в себе определенную опасность и от него следует отказаться. Вместо этого следует либо рассматривать наборы записей регистров, как самостоятельные блоки, либо вовсе отказаться от контроля движений. Т.е. контролировать исходные документы, и не обращать внимания на то, как их интерпретирует владелец.
Несмотря на то, что схему взлома никто не нашел, конкурс получился очень продуктивным.
В попытках найти схему взлома были выявлены несколько важных ньюансов.
1. VADIM1011985 практически сходу предложил менять движения документов, не трогая сами документы. Сама эта идея, что называется, лежит на поверхности. И полтора года назад, когда была представлена первая экспериментальная реализация приватного блокчейна, я ее конечно же учитывал. Но тогда я остановился на том, что документ можно представлять расширено. Добавляем к реквизитам и табличным частям еще и движения документа. Просто рассматриваем движения, как дополнительные табличные части и вопрос закрыт. Здесь скрыта одна неочевидная проблема, которая проявилась в результате обсуждения. Почему, собственно, я и считаю, что указавший на нее достоин вознаграждения, хоть это и не схема взлома.
Не секрет, что типовые конфигурации избыточны, если не сказать больше. Подключение приватного блокчейна к типовой конфигурации, очевидно, потребует действий по настройке такого подключения. В экспериментальной реализации приватного блокчейна, которую я представлял здесь полтора года назад, пользователю предлагалось расширенное представление документа. Кроме реквизитов и табличных частей, в такое представление входили движения документа. Можно было сказать, что есть обычные табличные части, а есть табличные части движений. Такой подход, действительно таит в себе определенную опасность и от него следует отказаться. Вместо этого следует либо рассматривать наборы записей регистров, как самостоятельные блоки, либо вовсе отказаться от контроля движений. Т.е. контролировать исходные документы, и не обращать внимания на то, как их интерпретирует владелец.
(366)
Особенно если эта голова непробиваема для здравого смысла и основанных на нем аргументов.
Что, собственно, мы и наблюдаем в данной теме.
Нельзя сказать, что эта невозможность очевидна каждому. Вы уверены, что это невозможно.
Я вообще-то имел в виду другое: невозможно опровергнуть затейливый бред, крепко сидящий в голове.
Особенно если эта голова непробиваема для здравого смысла и основанных на нем аргументов.
Что, собственно, мы и наблюдаем в данной теме.
2. spacecraft обратил внимание на то, что можно поменять местами наименования в справочнике. Если ваш алгоритм сериализации документа будет использовать ссылки ( в экспериментальной реализации, кстати, так оно и было), то у вас будет "дырка". Отсюда вывод - в сериализации должны быть использованы наименования, но не ссылки. А если мы все же хотим по каким-либо (я здесь не буду описывать - по каким, но они есть) причинам использовать ссылки, тогда изменения в соотвествующих справочниках должны быть также включены в журнал.
3. Самое серьезное замечание поступило от коллеги, который назвал себя математиком. dshershen86 утверждал, что можно подобрать коллизию и подменить исходные данные данными коллизии. Тут он, конечно, не прав по двум причинам.
Подбор коллизии простым перебором практически невозможен. На Земле сейчас просто нет таких вычислительных ресурсов. Коллизии для хэш-функций подбираются специальными алгоритмами, которые работают в сотни тысяч раз быстрее простого перебора. В настоящее время известен алгоритм для подбора коллизий хэш-функций первого поколения, SHA-1. Для второго поколения, SHA-2, такой алгоритм пока еще в стадии разработки. Разработчики пока смогли предложить алгоритм для усеченной версии хэш-функции, состоящей из 31 итерации. В то время как полная версия состоит из 64 итераций. Это означает, что сейчас можно смело пользоваться SHA256, не оглядываясь на коллизии. Что, кстати, и происходит в сети Bitcoin. Там применяется двойная SHA256. Когда (и если) будет разработан алгоритм поиска коллизий для SHA-2, можно будет просто перейти на SHA-3. И это первая причина.
Вторая заключается в том, что коллизия может не существовать в принципе. Например, можно точно сказать, что не существует однобайтовая коллизия SHA256 для исходного сообщения в один байт. Это может быть коллизия размером в килобайт или даже мегабайт, когда доделают алгоритм для SHA-2, тогда и узнаем. Сейчас важно понимать, что при поиске коллизий нам подойдет не любая, а только такая, которая будет представлять собой результат сериализации документа. Если у нас сначала идет номер документа с фиксированным размером в 10 байт, а затем ";" то нам потребуется найти коллизию, у которой 11-ым символом будет ";" и т.д.
Из всего этого есть один практический вывод. Использование строк переменной (и уж тем более неограниченной) длины, пусть даже и теоретически, но облегчают возможность подбора коллизий. И чтобы этого избежать, сериализация должна строиться на строках фиксированной длины.
Подбор коллизии простым перебором практически невозможен. На Земле сейчас просто нет таких вычислительных ресурсов. Коллизии для хэш-функций подбираются специальными алгоритмами, которые работают в сотни тысяч раз быстрее простого перебора. В настоящее время известен алгоритм для подбора коллизий хэш-функций первого поколения, SHA-1. Для второго поколения, SHA-2, такой алгоритм пока еще в стадии разработки. Разработчики пока смогли предложить алгоритм для усеченной версии хэш-функции, состоящей из 31 итерации. В то время как полная версия состоит из 64 итераций. Это означает, что сейчас можно смело пользоваться SHA256, не оглядываясь на коллизии. Что, кстати, и происходит в сети Bitcoin. Там применяется двойная SHA256. Когда (и если) будет разработан алгоритм поиска коллизий для SHA-2, можно будет просто перейти на SHA-3. И это первая причина.
Вторая заключается в том, что коллизия может не существовать в принципе. Например, можно точно сказать, что не существует однобайтовая коллизия SHA256 для исходного сообщения в один байт. Это может быть коллизия размером в килобайт или даже мегабайт, когда доделают алгоритм для SHA-2, тогда и узнаем. Сейчас важно понимать, что при поиске коллизий нам подойдет не любая, а только такая, которая будет представлять собой результат сериализации документа. Если у нас сначала идет номер документа с фиксированным размером в 10 байт, а затем ";" то нам потребуется найти коллизию, у которой 11-ым символом будет ";" и т.д.
Из всего этого есть один практический вывод. Использование строк переменной (и уж тем более неограниченной) длины, пусть даже и теоретически, но облегчают возможность подбора коллизий. И чтобы этого избежать, сериализация должна строиться на строках фиксированной длины.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот