1. mkalimulin 364 26.07.19 22:40 Сейчас в теме

Проверка возможности взлома приватного блокчейна

Предлагаю вознаграждение тому, кто опишет способ взлома приватного блокчейна.
Условия следующее:
Есть база данных. Пусть это будет типовая БП. Есть один владелец базы. У него есть полный доступ к базе и возможность делать любые транзакции. Владелец базы хочет, чтобы его действия стали прозрачными для некоторого контрагента, который является его поставщиком, и которого мы дальше будем называть проверяющим. С этой целью он создает журнал на основе блокчейна. Журнал содержит ИД документа, хэш документа, хэш начальный и хэш конечный. Владелец базы дает проверяющему доступ на чтение к базе и доступ на чтение к журналу. Проверяющий создает сам или получает от Владельца программу проверки. Как именно - не важно, потому что, в любом случае код проверяющей программы открыт и находится под контролем Проверяющего. Эта программа запускается регулярно и проверяет соотвествие хэш-сумм и содержимого документов, соотвествие начальных и конечных ключей, и, наконец, соотвествие последнего ключа предыдущей проверки этому же ключу для текущей проверки. Т.е. провели проверку журнала. Последний блок Х содержал ключ Y. Через некоторое время проводим проверку снова и проверяем, чтобы конечный ключ блока Х был равен Y.
Прозрачность заключается в том, что Проверяющий после каждой проверки будет получать список новых документов. И может быть уверен, что никакие старые документы не менялись и не удалялись.
Для получения вознаграждения требуется описать последовательность действий Владельца с базой и с журналом, которая приведет к тому, что эти действия будут скрыты от Проверяющего. Требуется привести доказательства того, что сам факт этих действий не будет зарегистрирован проверяющей программой.
Срок проведения данного конкурса - до 10.08.2019.
Вознаграждение за ответ
Показать полностью
Найденные решения
10. vadim1011985 64 28.07.19 23:09 Сейчас в теме +5 $m
(1) ручная операция сторно документов ( или просто ручные операции) , позволит изменить движения документов ( хотя и текущим числом ) для проверочной программы это будет как новый документ , и по сути основной документ не меняется и хеши будут сходится ( ведь движения меняем в другим документом ) но данные для базы будут изменены можно например полностью сторнировать движения документов.
17. spacecraft 29.07.19 09:16 Сейчас в теме +5 $m
(1) кто помешает
1. переименовать Поставщика и получателя и получить те же документы с другими контрагентами? В Журналах(документах) только ссылки на справочники. Сами данные справочников в журнале не сохраняются.
2. обработкой поменять записи в регистрах не затрагивая сами документы. Журнал данные регистра не хранит.
294. dshershen86 07.08.19 14:05 Сейчас в теме +5 $m
(282)
Например мне удалось найти коллизию и я поменял контрагента и адрес, так что бы в сумме хеш по алгоритму не изменился. Вы будете видеть все тот же документ, но с отличными данными, ключи совпадут. Если ваш хеш алгоритм уникален для любого состава данных, то это по сути версионирование, снимок последнего состояния. Это уже не совсем хеш.
Как поможет соль - просто нереально будет определить алгоритм хеширования по хеш-таблице, точнее, цена поиска будет стремиться к безконечности и будет не выгодна.
Остальные ответы
Избранное Подписка Сортировка: Древо
313. TODD22 17 08.08.19 12:20 Сейчас в теме
(311)Я нет, так как не обладаю информацией о том что вы понимаете под ценностью, не могу измерить ценность количественно, не имею доступа к "закромам ИС" что бы её попробовать измерить(хотя бы статистику из метрики). Вы можете?
316. mkalimulin 364 08.08.19 12:22 Сейчас в теме
(313) А вы отвечайте, исходя из того, что ВЫ понимаете под ценностью.
317. TODD22 17 08.08.19 12:26 Сейчас в теме
(316)
А вы отвечайте, исходя из того, что ВЫ понимаете под ценностью.

То что ценно для меня может ничего не значить для миллионов других людей. Мы же не можем ориентироваться в таком вопросе на моё или ваше мнение о ценности той или иной статьи.
Потому что такое восприятие зависит от настроения, образования, окружающей среды, воспитания и тд. И мы дойдём до "сколько людей столько и мнений".
Хотя многие предпочтения нейробиологи всё же могут объяснить.
319. mkalimulin 364 08.08.19 12:29 Сейчас в теме
(317) Я не справшиваю "миллион других людей", я спрашиваю вас )))
321. TODD22 17 08.08.19 12:30 Сейчас в теме
(319)Ещё раз. Мы не можем ориентироваться на моё или ваше представление о ценности.
322. TODD22 17 08.08.19 12:32 Сейчас в теме
(319)ну раз спрашиваете меня то могу точно сказать что понимание мной ценности статьи на ИС лежит за пределами "плюсов и минусов".
323. mkalimulin 364 08.08.19 12:40 Сейчас в теме
(322) Вот теперь более или менее понятно.
Т.е. вы лично на плюсы и минусы никакого внимания не обращаете?
324. TODD22 17 08.08.19 12:42 Сейчас в теме
(323)
Т.е. вы лично на плюсы и минусы никакого внимания не обращаете?

Михаил пишу ещё раз и медленно:
"понимание мной ценности статьи на ИС лежит за пределами "плюсов и минусов""
325. mkalimulin 364 08.08.19 12:43 Сейчас в теме
(324) Но вы замечаете, что у какой-то статьи только плюсы, а у какой-то и плюсы и минусы? Или этот факт проходит мимо вашего внимания?
326. TODD22 17 08.08.19 12:49 Сейчас в теме
(325)
Или этот факт проходит мимо вашего внимания?

Михаил что вам не понятно из написанного?
Пишу вроде русским языком, чёрными буквами по белому фону. В чём сложность?

Есть плюсы и минусы, есть полезность статьи. Плюсы и минусы в моём понимании это отношение их поставивших к материалу, подаче или автору("Увидел статью username ставь плюс не глядя", "Плюсанул автора не глядя" и тд вы же видели такие комментарии?) Так это ценность или отношение?
327. mkalimulin 364 08.08.19 13:10 Сейчас в теме
(326) Допустим. А "минусанул" не глядя бывает?
328. TODD22 17 08.08.19 13:26 Сейчас в теме
(327)
А "минусанул" не глядя бывает?

Почему нет? Есть авторы которым минусы ставят даже не читая их статей. Или вы считаете что тот кто поставил плюс или минус прочитал всё от начала до конца, потом подумал, оценил и принял решение? Я так думаю половина оценок выставляется на эмоциях и те кто их ставит принимают решение об этом не прочитав и 1/3 статьи.

Интересная задача прогнозирование отклика на статью :)
332. mkalimulin 364 08.08.19 13:56 Сейчас в теме
(328) Плюс не глядя, и минус не глядя ставят одинаково часто? Ситуация симметрична?
333. TODD22 17 08.08.19 13:58 Сейчас в теме
(332)Не знаю, надо проверять. Но проверить это можно только зная сколько тот или иной пользователь провёл за чтением статьи.
Ну и плюсы ставят чаще чем минусы. Есть ещё момент, плюсы в статьях на сколько знаю может ставить "любой", а минусы "не только лишь все" а те у кого рейтинг более 30.
334. mkalimulin 364 08.08.19 14:10 Сейчас в теме
(333) Я не зря обращаю внимание на "не глядя".
Допустим в статье ничего нет. Ни новой информации, ни какого-нибудь неожиданного взгляда на известные проблемы, ни даже какого-нибудь простенького лайфхака. Но есть забавные картинки и несколько более или менее удачных шуток.
С какой вероятностью такая статья соберет плюсы? С какой вероятностью она соберет минусы?
Другая статья выдвигает очень неожиданные и спорные тезисы. Кому-то нравится свежая мысль. Кто-то категорически несогласен. Но равнодушных практически нет.
Что будет с этой статьей в плане плюсов и минусов?
335. TODD22 17 08.08.19 14:19 Сейчас в теме
(334)Михаил прогнозирование отклика довольно не тривиальная задача и сложная работа. Прогнозирование и теоретезирование это разные вещи!
336. mkalimulin 364 08.08.19 14:27 Сейчас в теме
(335) Т.е. вы затрудняетесь спрогнозировать ситуацию с плюсами и минусами для этих двух статей?
337. TODD22 17 08.08.19 15:11 Сейчас в теме
338. mkalimulin 364 08.08.19 15:25 Сейчас в теме
339. TODD22 17 08.08.19 15:48 Сейчас в теме
(338)Рад за вас.
Прогнозирование как в одной шутке:
"
-Какова вероятность выйдя на улицу встретить динозавра?
- 50/50 или встречу или нет.
"
329. TODD22 17 08.08.19 13:40 Сейчас в теме
(327)Кстати не вы ли как то прошлись "минусами" по статьям одного автора за то что он минусанул одну из ваших?
330. mkalimulin 364 08.08.19 13:54 Сейчас в теме
(329) Не я. Я вообще минусы не ставлю.
331. TODD22 17 08.08.19 13:55 Сейчас в теме
312. TODD22 17 08.08.19 12:19 Сейчас в теме
(309)
Если брать в среднем, то какие статьи ценнее: статьи только с плюсами или статьи с плюсами и минусами?

Я вот старался... писал... а вы так и не поняли... попробуйте перечитать несколько раз и медленно.
314. mkalimulin 364 08.08.19 12:21 Сейчас в теме
(312) Вы сможете ответить, если вам объяснят, что такое ценность и как она измеряется?
315. TODD22 17 08.08.19 12:21 Сейчас в теме
(314)
Вы сможете ответить, если вам объяснят, что такое ценность и как она измеряется?

Объясните :)
318. mkalimulin 364 08.08.19 12:28 Сейчас в теме
(315) А зачем? Если у человека нет собственного представления о ценностях, то зачем ему чего-то объяснять? Можно только удивиться тому, как вам удается выживать в этом мире)))
320. TODD22 17 08.08.19 12:29 Сейчас в теме
(318)Вы ничего не употребляли сегодня?
У меня есть "собственное" представление о "ценности" но оно моё и может отличаться от вашего или чьего либо ещё. Я вам об этом в (317) вроде бы написал.
279. dshershen86 07.08.19 11:41 Сейчас в теме
(275)Если У Вас есть ограниченное количество данных версионирование которых Вы ведете, то конечно же работать будет, но это единичная реализация, на никакую уникальность не претендующая. Это все равно, что утверждать, что в крестики нолики всегда будет ничья. Но если оба понимают правила игры.

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

О ключах, на основании чего формируется ключ Х. Укажите формулу.
280. mkalimulin 364 07.08.19 11:49 Сейчас в теме
(279) Ключ начальный=ключ конечный предыдущего блока.
Ключ конечный = хеш документа и начального ключа.
Должно быть очевидно.

Мы ищем возможные действия владельца, которые останутся незамеченными проверяющим.
281. dshershen86 07.08.19 12:08 Сейчас в теме
(280)Зачем я спросил, что если проверяются только результирующие значения, то взломать можно анализируя хеш таблицу и зная алгоритм и его коллизии можно подменить один массив данных на другой, а хеш не изменится. Рекомендую на Гуглить тему Крипто соль.
282. mkalimulin 364 07.08.19 12:38 Сейчас в теме
(281) Но как можно использовать коллизии для бух документов? У вас есть изначальный документ и его хэш.
Допустим вам удалось найти коллизию для этого хэша. Какова вероятность того, что используя эту коллизию, вы получите бух документ?
И каким образом криптосоль может решить эту гипотетическую проблему?
294. dshershen86 07.08.19 14:05 Сейчас в теме +5 $m
(282)
Например мне удалось найти коллизию и я поменял контрагента и адрес, так что бы в сумме хеш по алгоритму не изменился. Вы будете видеть все тот же документ, но с отличными данными, ключи совпадут. Если ваш хеш алгоритм уникален для любого состава данных, то это по сути версионирование, снимок последнего состояния. Это уже не совсем хеш.
Как поможет соль - просто нереально будет определить алгоритм хеширования по хеш-таблице, точнее, цена поиска будет стремиться к безконечности и будет не выгодна.
296. mkalimulin 364 07.08.19 14:24 Сейчас в теме
(294) Мне кажется, что все гораздо проще. Используем общеизвестный алгоритм, например SHA256 или двойную SHA256.
Какова, для начала, цена поиска коллизии для конкретного хэша? Как вы ее будете искать?
Вот у вас есть товар, количество, цена. Будете перебирать все возможные варианты? Какова вероятность, того что такую коллизию вообще невозможно подобрать? Т.е. коллизии есть, но ни одна из них не может содержать названия какого-либо товара.
297. dshershen86 07.08.19 15:27 Сейчас в теме
(296)Абсолютно не важно sha 256 или, что-то еще. В мире хакеров, если есть исходные данные и зашифрованные, а также осутствует погрешность(соль), то получить обратным преобразованием алгоритм возможно. Зная колизии алгоритма можно подменить данные.
Испортить данные это ведь тоже изменить документ не так ли.

Еще раз, я не понимаю. Мы доказываем, что это ВОЗМОЖНО. Или что это МАЛОВЕРОЯТНО?
Алгоритм действий. Берем таблицы документов с наборами данных, берем хеш. Берем или пишем анализатор, который проверяет на стандартные алгоритмы, подбираем преобразования, что бы получить данный хеш, находим алгоритм. Меняем данные так, что бы хеш не изменился. Даже если в данных станет ахинея, все равно это выполняет условия задачи.
299. mkalimulin 364 07.08.19 18:34 Сейчас в теме
(297) Подберите коллизию SHA256 к следующей строке:

20135;Сахар-песок пакет 0,9 кг;112;78

Учтите, что в коллизии обязательно должны быть три символа ";".
Подумайте над этим и вы поймете, что:
1) для поиска вам придется перебрать количество вариантов, сравнимое с количеством атомов во всей вселенной
2) не факт, что такая коллизия вообще существует
303. user928779 08.08.19 08:13 Сейчас в теме
(299)
Учтите, что в коллизии обязательно должны быть три символа ";"

То есть хешируете вы даже не "содержимое документа", как громко заявляли ранее, а уже что-то свое, кондово-посконное... Ну-ну.
304. mkalimulin 364 08.08.19 09:16 Сейчас в теме
(303) В смысле? Хешируется содержимое документа. Но, как вы наверно догадываетесь, нет такой команды: хэшируй документ. Данные документа должны быть сначала сериализованы. Подумайте над этим.
360. user928779 10.08.19 16:05 Сейчас в теме
(304) О, так вы даже сериализацию имени себя изобрели. Похвальное усердие.
И как она, сериализация, устойчива к изменению схемы базы?
361. mkalimulin 364 10.08.19 17:21 Сейчас в теме
(360) Какое это имеет отношение к теме?
351. dshershen86 09.08.19 13:49 Сейчас в теме
(299)
20135;Сахар-песок пакет 0,9 кг;112;78


Стоп, за подбор я бы запросил 200тыс $.
Мы говорим ВОЗМОЖНО ЛИ ЭТО?
Теоретически ? - да. Сложно ли ?- да.

Поможет Вам такой подход - да. Об этом я уже много говорил. Но и говорил, что бы покрыть возможность обмануть - этого мало. Так как отчеты строятся не на документах. Да и возможности повлиять на БД, даже если вы хеш пишите тригерами - обширна.

Зачем я тратил время.
353. mkalimulin 364 09.08.19 14:05 Сейчас в теме
(351) Вы напрасно с такой легкостью говорите: возможно. Это требует доказательств.
Это хорошо, что вы знаете цену подбора. А вы бы согласились бы на условие, что если вы не подберете за месяц, тогда вы платите 200 тыс.? Подумайте над этим.

А в этом и смысл блокчейна. Несмотря на то, что вы можете делать с базой все, что хотите, все ваши действия прозрачны для проверяющего.
356. dshershen86 09.08.19 18:02 Сейчас в теме
(353)ОФФТОП. Но думаю, да. За 200тыс долларов предоплаты я бы помог Питеру Тоду найти ребят :-).

По теме - я математик, если коллизии существуют, то можно найти. Остальное вопрос техники, алгоритмов, вычислительных мощностей. За такую сумму можно построить огромную бот ферму брутфорсеров. и приблишение в 2^128 не такое и огромное число поиска. Но дискусия не о том.
357. mkalimulin 364 09.08.19 18:38 Сейчас в теме
(356) А без предоплаты вы бы не взялись? Вот то-то и оно!
Надо ведь найти не любую коллизию, а очень редкую коллизию. Я думаю, вы продешевили)))
И если уж вы математик, в чем я сомневаюсь, вы должны понимать, что коллизии может вообще не быть.
358. vadim1011985 64 09.08.19 20:39 Сейчас в теме
(357) не очень понял почему надо найти очень редкую коллизию - и что лично вы понимаете под словом коллизия , может вы о разных вещах говорите ?
359. mkalimulin 364 09.08.19 21:11 Сейчас в теме
(358) Потому что вы должны подбирать не любые данные, а лишь те, что получаются в результате сериализации документа.
Коллизия - она и есть коллизия. Что еще можно под ней понимать, кроме одного хэша для разных данных?
283. mkalimulin 364 07.08.19 12:40 Сейчас в теме
(281) Проверяются документы.
340. vipetrov2 09.08.19 07:30 Сейчас в теме
Автор сам только на половину понимает, что пишет.
В данном случаи что бы проверяющему определить была или не была изменена база нужно иметь свою копию базы целиком или частично. А проверка делается путем сверки своей копии с оригиналом. Если своей копии у проверяющего не будет, то сверять не с чем, база может за ночь полностью смениться и все цепочки хешей будут сходиться, нужно проверяющему иметь хотя бы 1 последний хэш документа базы.
Тот же самый способ проверки организуется обычным копированием базы проверяющим.
Наличие хеша документа в базе, дает возможно копировать проверяющему не все документы целиком, а только их хеши, т.е. меньший объем информации.
Наличие цепочки хешей, дает возможность копировать проверяющему не все хеши всех документов, а только определенную долю. Таким образом для последующей сверки проверяющим базы на предмет ее изменения, достаточно иногда копировать хеши некоторых свежих документов.

Такая система обеспечивает только одностороннее доверие проверяющего к базе. А доверия к оценке проверяющего третьей стороной нет. Проверяющий может сказать, что база изменена, потому что его частичная копия не сходится с базой. Что бы разрешить этот конфликт, 3 сторона тоже должна иметь частичную копию базы, при чем с момента раньше конфликта между базой и проверяющим.
341. mkalimulin 364 09.08.19 09:26 Сейчас в теме
(340) Про последний хэш в условии сказано. Проверяющий имеет доступ на чтение к базе и журналу. Проверяющий не хранит у себя ничего, кроме последнего хэша. Этого достаточно для того, чтобы контролировать изменения.
Вы понимаете разницу между сверкой двух баз и проверкой журнала?
Третий лишний)))
371. vipetrov2 12.08.19 04:23 Сейчас в теме
(341) Если не будет своей копии, то сравнивать не с чем. Админ по собственным желаниям или по велению начальства, может заменить базу целиком и пересчитать все цепочки хешей, что бы алгоритм проверки показывал, что никто документы не изменял.
А третьей стороной всегда может быть суд, внутренняя проверка компании, новый собственник компании.
372. mkalimulin 364 12.08.19 08:45 Сейчас в теме
(371) Вместо копии базы достаточно хранить один хэш. Этого достаточно для того, чтобы обнаружить любое изменение. С другой стороны, хранение копии базы самой по себе, без применения блокчейна, недостаточно для обнаружения изменений.
373. vipetrov2 12.08.19 11:27 Сейчас в теме
(372) Я про это и писал. Хэш последнего блока и является контрольной суммой для всех контролируемых документов(частичная копия базы) и его надо хранить у себя.
А вот хранение копии базы целиком, как раз дает 100% гарантию при сравнении, что базу изменяли или нет. А хранение последнего хеша дает гарантию 99% или очень близкую к 100%, потому что существуют коллизии для хеша.
Еще есть проблема, если не делалась копия базы или последнего хэша, например, 2 дня. То эти последние 2 дня, база может меняться, как угодно, без отслеживания этого события проверяющим.

И админ может базу целиком заменить. А потом с последним хэшем, ни кому не докажешь, что ты прав. Доказательством будет только документ с печатью.

А "красивые" хэши и распределенные базы для того и нужны, что бы админы за ночь не могли пересчитать все хэши и тогда даже последний хэш хранить не обязательно.
374. mkalimulin 364 12.08.19 12:43 Сейчас в теме
(373) Про распределенные базы мы не говорим. У нас блокчейн - приватный. О коллизиях я уже подробно написал в (368). Насчет коллизий вы неправы. А также вы неправы в том, что полная копия базы дает 100% гарантию.
100% гарантию дает блокчейн, а полная копия в общем случае дает 0%.
375. vipetrov2 13.08.19 06:54 Сейчас в теме
(374) Что это за бред, копия дает гарантию 0%? Смысл слова копия - это полное воспроизведение базы данных. Если нет этого воспроизведения, то и нет копии.
Такое ощущение, что ботом разговариваешь, который только на ключевые слова реагирует, не вникая в смысл текста.
376. mkalimulin 364 13.08.19 10:17 Сейчас в теме
(375) Вы разговариваете с человеком, который очень хорошо представляет себе о чем идет речь. На практике, которой у вас, видимо, никогда не было.
Вот у вас на руках база 200Гб. Вы ее сутки качали. Наконец скачали. Дальше что?
378. TODD22 17 15.08.19 12:14 Сейчас в теме
(372)
Вместо копии базы достаточно хранить один хэш. Этого достаточно для того, чтобы обнаружить любое изменение.

А как будет работать вся эта схема в такой ситуации:
Мы обменялись документами, посчитали хэш. Я же правильно понимаю что мне нужно хранить только последний хэш?
Что будет если вы исправляете какой то документ в прошлом месяце например? Вы это делаете в вашей базе. Я проверяю хэш который хранится у меня и он не совпадает?
379. mkalimulin 364 15.08.19 13:09 Сейчас в теме
(378) Исправление так или иначе попадет в конец журнала.
Смысл всего это дела в том, что вы делаете проверку и на выходе получаете список как новых, так и изменившихся документов.
380. TODD22 17 15.08.19 13:38 Сейчас в теме
(379)Так я же не храню весь список. Вы же предлагаете хранить мне только хэш от последней операции.
Что будет с моим хэшем если вы задним числом измените документ и пересчитаете. Получается с помощью того хэша который я храню я уже не смогу проверить цепочку?
381. mkalimulin 364 15.08.19 14:21 Сейчас в теме
(380) Вы храните хэш только для того,чтобы быть уверенным, что цепочка не подменена. А собственно проверку вы можете проводить по цепочке, которая хранится у владельца.
382. TODD22 17 15.08.19 14:22 Сейчас в теме
(381)То есть если я вижу что мой хэш не сходится, я должен проверить всю цепочку у вас? То есть пересчитать все операции с начала года?
383. mkalimulin 364 15.08.19 14:48 Сейчас в теме
(382) Если вы видите, что хэш не сходится, вы перестаете доверять. Конец фильма.
384. TODD22 17 15.08.19 15:01 Сейчас в теме
(383)Так если при изменении чего либо задним числом у вас хэши не сходятся я перестаю доверять. Как вам вернуть моё доверие? Мы же дальше работать должны. И правки в документах это же нормальная рабочая практика.
385. mkalimulin 364 15.08.19 15:03 Сейчас в теме
(384) Я же вам уже сказал, изменения "всплывают" в конеце жунала. Что тут непонятного? Хэши всегда сходятся.
386. TODD22 17 15.08.19 15:10 Сейчас в теме
(385)
Что тут непонятного?

Вот это.
Если вы видите, что хэш не сходится, вы перестаете доверять.

Хэши всегда сходятся.


Ещё раз.

Вы что то переделали в прошлом периоде, не с целью что то подделать, а например исправили какие то документы. Ваш новый хэш с моим контрольным не сойдутся?
388. mkalimulin 364 15.08.19 15:17 Сейчас в теме
(386) У вас есть два способа.
Первый. Вы никогда не исправляете старые документы. Если надо изменить что-то, вы вводите новый документ. Как понимаете, в этом случае хэши всегда сходятся.
Второй, более привычный для 1С. Вы исправляете старый документ. Старый блок в журнале помечается, как исправленный. В конец журнала добавляется новый блок. У старого блока хэш не соответствует данным документа, но мы его и не проверяем. Мы проверяем новый блок. У нового блока хэш и данные сходятся.
Способы разные, результат один - все изменения "всплывают".
389. TODD22 17 15.08.19 15:23 Сейчас в теме
(388)
Способы разные, результат один - все изменения "всплывают".

Я понял что изменения "всплывут", вопрос в другом, всплыли изменения, как вы будете возвращать доверие? Я же должен доверять вашей системе и при этом хранить только последний хэш.
Пришёл утром на работу, хэши не сошлись. Вы мне говорите что вы что то исправили. Теперь контрольный хэш новый. Но у меня есть только старый хэш с помощью которого я проверить не могу и новый который я как то должен проверить. Или нет?

В общем суть вопроса в возврате доверия если хэши не сошлись. Вы меня не обманывали, а именно исправили ошибку в вашей базе, логично хэши не сходятся. Как будем работать дальше?
390. mkalimulin 364 15.08.19 15:54 Сейчас в теме
(389) Хеши сошлись. Вы пришли утром на работу, а вам программа говорит: у вас три новых документа и еще один изменили, проверяйте.
А вот если хэши не сошлись, тогда программа вам говорит: эти ребята сознательно сломали журнал, прекращайте с ними работу.
392. TODD22 17 15.08.19 16:10 Сейчас в теме
(390)Тогда не понятно что вы имели ввиду под тем что нужно хранить только последний хэш что бы быть уверенным что ничего не поменялось.
394. mkalimulin 364 15.08.19 19:53 Сейчас в теме
(392) Чтобы быть уверенным, что ничего не поменялось нужно использовать журнал на основе блокчейна. При этом, сам журнал может храниться у владельца. А вам достаточно хранить у себя только один хэш.
396. TODD22 17 15.08.19 20:33 Сейчас в теме
(394)Так вот у меня и вопрос. Если я храню один хэш, вы меняете что то у себя в базе, этот один хэш то же изменится. Я сверяю свой с вашим, вы мне говорите что вы изменяли документы задним числом из за ошибки.
Что мне нужно сделать что бы после этого вновь "доверять" вашему хэшу? Пересчитать весь журнал?
397. mkalimulin 364 15.08.19 20:41 Сейчас в теме
(396) Этот один хэш не изменится.
398. TODD22 17 15.08.19 21:27 Сейчас в теме
(397)То есть вы можете что то изменить в базе и хэш по которому вы рекомендуете проверять не изменится?
399. mkalimulin 364 15.08.19 21:57 Сейчас в теме
(398) Проверка делается по журналу, а не по одному хэшу.
387. TODD22 17 15.08.19 15:11 Сейчас в теме
(385)
"всплывают" в конеце жунала.

Конец журнала это хэш который я храню у себя и по нему проверяю всю цепочку?
391. mkalimulin 364 15.08.19 15:56 Сейчас в теме
(387) Конец журнала - это конец журнала. Т.е. некоторое количество блоков в конце. А сохраненный хэш - это сохраненный хэш. Он вам нужен для того, чтобы быть уверенным, что журнал не подменили с момента прошлой проверки.
393. vadim1011985 64 15.08.19 16:14 Сейчас в теме
(391) Еще раз повторю свой вопрос про права RLS см. 377
395. mkalimulin 364 15.08.19 19:58 Сейчас в теме
(393) Ну а что RLS? Можно ведь создать вообще другую базу и туда что-то писать. И что?
Мы не разбираем вопрос, как получить доступ к недоступному, или как увидеть невидимое. Мы решаем вопрос - как увидеть видимое.
342. vadim1011985 64 09.08.19 11:10 Сейчас в теме
Достаточно будет сделать свертку базы и журнал (а точнее проверка журнала ) перестанет работать
343. mkalimulin 364 09.08.19 11:28 Сейчас в теме
(342) Будет работать. Достаточно будет обрезать журнал с начала до даты свертки.
344. vadim1011985 64 09.08.19 12:02 Сейчас в теме
(343) И как он проверит начальный хеш , если сам документ удален и внесенные остатки ручными операциями + часть документов будет помечена на удаления которые не смогут удалится .т.е. хеши оставшихся документов изменятся если стоит проверка на пометку на удаления , а какя понимаю она у вас проверяется
345. mkalimulin 364 09.08.19 12:07 Сейчас в теме
(344) Зачем проверять начальный хэш? Проверяются все блоки и целостность цепочки. Т.е. соотвествие конечных ключей начальным. Для превого блока нет предшественника, поэтому его начальный ключ не проверяется.
346. vadim1011985 64 09.08.19 12:12 Сейчас в теме
(345) Стоп вот пример цепочки

Документ1 - Документ2 - тут произошла Свертка базы - Документ3

Вроде предыдущие документы есть - значит должен быть начальный хэш , Если вы предлагаете обрезать журнал и начинать с нового блока - то можно спокойной изменить старый денные не боясь их обнаружения
347. mkalimulin 364 09.08.19 13:00 Сейчас в теме
(346) Как вы их измените? Вы же их обрезали. Все - их нет. Они для нас не существуют. Мы их исключили из рассмотрения в принципе. Вместо этих документов есть один документ "Ввод начальных остатков". А его мы будем контролировать обычным образом.
348. vadim1011985 64 09.08.19 13:19 Сейчас в теме
(347) Свертка происходит с помощью ручных операций , Сам факт "обрезания" журнал говорит о том что можно изменять данные - и как проверяющий будет доказывать что вы не изменили данные перед сверткой , имея на руках последний хэш ?

т.е. Алгоритм таков - меняете документы проверяющего - делаете свертку базы - производите удаление помеченных объектов. Для проверяющего говорите что копий баз нет
349. mkalimulin 364 09.08.19 13:26 Сейчас в теме
(348) А еще вы можете переписать историю или переписать завещание. И проверяющий это не заметит.
Удаление документов при свертке означает, что мы их больше не рассматриваем. Они для нас теперь посторонние, как история или завещание.
350. vadim1011985 64 09.08.19 13:30 Сейчас в теме
(349) ни че себе так заявления - что бы история была посторонней - Ну , Ок

а если я изменю документы так что вы мне должны миллион - ну что будем считать за правду ? История наших взаиморасчетов удалена - это прошлое , живем настоящим - гоните миллион ))
352. dshershen86 09.08.19 13:56 Сейчас в теме
(350)А зачем удалять из журнала документ. Была же ссылка и хеш. Не стало документа, значит, что то изменилось и доверять данным нельзя. В темболее понятно какие документы изменились. Я так понял здесь вопрос, можно ли говорить, что данные не изменились, если хеш документов не менялся. Можно ли доверяться такой технологии. Автор еще упомянул, что он рассматривает, даже не документы а абстрактные наборы данных в документах. Речи нет ни о движении, ни о отчетах. Вся эта реализация - чистая теория, и как конь в вакууме - частный случай.
355. mkalimulin 364 09.08.19 14:15 Сейчас в теме
(352) Здесь идет обсуждение специфической темы, касающейся свертки базы.
354. mkalimulin 364 09.08.19 14:14 Сейчас в теме
(350) Я недостаточно точно выразился. Я хотел сказать, что вы можете переписать историю Куликовской битвы и проверяющий этого не заметит. Из контекста это должно было быть понятно.
Еще раз. Нет никаких документов. Их удалили. Все. Что вы там поменяли или поменяете уже никого не волнует. Есть один новый документ "Ввод начальных остатков". И этот документ контролируется обычным образом. Проверяющий его видит. На этом все. Мы не обсуждаем содержание документов. Мы обсуждаем их прозрачность.
Вы говорите: владелец впишет в документ начальных остатков миллион. Ну и что? Он может и не в документ начальных остатков это написать, а, например, в документ "Списание безналичных денежных средств" или в документ "Возврат товаров". Какая разница? Мы же сразу договорились, что владелец может написать все, что хочет. Наша задача - увидеть все, что он напишет.
362. mkalimulin 364 11.08.19 09:00 Сейчас в теме
Подведу итоги конкурса.
Несмотря на то, что схему взлома никто не нашел, конкурс получился очень продуктивным.
В попытках найти схему взлома были выявлены несколько важных ньюансов.
1. VADIM1011985 практически сходу предложил менять движения документов, не трогая сами документы. Сама эта идея, что называется, лежит на поверхности. И полтора года назад, когда была представлена первая экспериментальная реализация приватного блокчейна, я ее конечно же учитывал. Но тогда я остановился на том, что документ можно представлять расширено. Добавляем к реквизитам и табличным частям еще и движения документа. Просто рассматриваем движения, как дополнительные табличные части и вопрос закрыт. Здесь скрыта одна неочевидная проблема, которая проявилась в результате обсуждения. Почему, собственно, я и считаю, что указавший на нее достоин вознаграждения, хоть это и не схема взлома.
Не секрет, что типовые конфигурации избыточны, если не сказать больше. Подключение приватного блокчейна к типовой конфигурации, очевидно, потребует действий по настройке такого подключения. В экспериментальной реализации приватного блокчейна, которую я представлял здесь полтора года назад, пользователю предлагалось расширенное представление документа. Кроме реквизитов и табличных частей, в такое представление входили движения документа. Можно было сказать, что есть обычные табличные части, а есть табличные части движений. Такой подход, действительно таит в себе определенную опасность и от него следует отказаться. Вместо этого следует либо рассматривать наборы записей регистров, как самостоятельные блоки, либо вовсе отказаться от контроля движений. Т.е. контролировать исходные документы, и не обращать внимания на то, как их интерпретирует владелец.
365. user856012 10 11.08.19 10:31 Сейчас в теме
(362)
Несмотря на то, что схему взлома никто не нашел
Потому что это невозможно.
366. mkalimulin 364 11.08.19 13:11 Сейчас в теме
(365) Нельзя сказать, что эта невозможность очевидна каждому. Вы уверены, что это невозможно. А кто-то другой, нет. В этой ветке активно участвовал человек, который утверждал нечто прямо противоположное вашему.
367. user856012 10 11.08.19 16:32 Сейчас в теме
(366)
Нельзя сказать, что эта невозможность очевидна каждому. Вы уверены, что это невозможно.
Я вообще-то имел в виду другое: невозможно опровергнуть затейливый бред, крепко сидящий в голове.

Особенно если эта голова непробиваема для здравого смысла и основанных на нем аргументов.

Что, собственно, мы и наблюдаем в данной теме.
369. mkalimulin 364 11.08.19 16:50 Сейчас в теме
(367) Вы представили схему взлома? Я что-то пропустил?
363. mkalimulin 364 11.08.19 09:01 Сейчас в теме
Вторая и третья часть будут вскоре.
364. mkalimulin 364 11.08.19 10:21 Сейчас в теме
2. spacecraft обратил внимание на то, что можно поменять местами наименования в справочнике. Если ваш алгоритм сериализации документа будет использовать ссылки ( в экспериментальной реализации, кстати, так оно и было), то у вас будет "дырка". Отсюда вывод - в сериализации должны быть использованы наименования, но не ссылки. А если мы все же хотим по каким-либо (я здесь не буду описывать - по каким, но они есть) причинам использовать ссылки, тогда изменения в соотвествующих справочниках должны быть также включены в журнал.
368. mkalimulin 364 11.08.19 16:48 Сейчас в теме
3. Самое серьезное замечание поступило от коллеги, который назвал себя математиком. dshershen86 утверждал, что можно подобрать коллизию и подменить исходные данные данными коллизии. Тут он, конечно, не прав по двум причинам.
Подбор коллизии простым перебором практически невозможен. На Земле сейчас просто нет таких вычислительных ресурсов. Коллизии для хэш-функций подбираются специальными алгоритмами, которые работают в сотни тысяч раз быстрее простого перебора. В настоящее время известен алгоритм для подбора коллизий хэш-функций первого поколения, SHA-1. Для второго поколения, SHA-2, такой алгоритм пока еще в стадии разработки. Разработчики пока смогли предложить алгоритм для усеченной версии хэш-функции, состоящей из 31 итерации. В то время как полная версия состоит из 64 итераций. Это означает, что сейчас можно смело пользоваться SHA256, не оглядываясь на коллизии. Что, кстати, и происходит в сети Bitcoin. Там применяется двойная SHA256. Когда (и если) будет разработан алгоритм поиска коллизий для SHA-2, можно будет просто перейти на SHA-3. И это первая причина.
Вторая заключается в том, что коллизия может не существовать в принципе. Например, можно точно сказать, что не существует однобайтовая коллизия SHA256 для исходного сообщения в один байт. Это может быть коллизия размером в килобайт или даже мегабайт, когда доделают алгоритм для SHA-2, тогда и узнаем. Сейчас важно понимать, что при поиске коллизий нам подойдет не любая, а только такая, которая будет представлять собой результат сериализации документа. Если у нас сначала идет номер документа с фиксированным размером в 10 байт, а затем ";" то нам потребуется найти коллизию, у которой 11-ым символом будет ";" и т.д.
Из всего этого есть один практический вывод. Использование строк переменной (и уж тем более неограниченной) длины, пусть даже и теоретически, но облегчают возможность подбора коллизий. И чтобы этого избежать, сериализация должна строиться на строках фиксированной длины.
370. mkalimulin 364 11.08.19 16:54 Сейчас в теме
Хочу еще раз поблагодарить всех, кто принял участие в данном конкурсе и пригласить всех желающих принять участие в "полевых" испытаниях приватного 1С блокчейна, которые начнутся ориентировочно в конце августа-начале сентября.
377. vadim1011985 64 13.08.19 21:31 Сейчас в теме
Ещё один момент , что на счёт прав RLS ? Допустим ограничить доступ проверяющему например по складу (или по другому реквизиту) , проверяющий не сможет видеть документы , соотвественно журнал они не попадут
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Москва
зарплата от 150 000 руб. до 150 000 руб.
Полный день

Консультант 1С
Нижний Новгород
зарплата до 100 000 руб.
Полный день

Программист стажер 1С
Нижний Новгород
зарплата от 30 000 руб.
Полный день

Программист 1С
Нижний Новгород
зарплата до 100 000 руб.
Полный день

Программисты 1С УТ / БУЗ/ЗУП / БИТ ФИНАНС
Москва
зарплата от 100 000 руб. до 180 000 руб.
Полный день