Яндекс.Диск закэшировал мой хомяк?

Предположу, что файлы с теми же контрольными суммами у них уже имелись.

Главное чтобы у яндекса не оказалось контрольной суммы личности каждого человека. А то так хрясь и можно так с каждым…

Верно. И я это упомянул в предыдущем ответе. Проблема в том, что у альфа-частицы масса меньше, а не больше, чем у двух ядер дейтерия. То есть, если мы исходим из того, чтобы прибавить сюда частицы перенсчики ядерных взаимодействий, и считаем, что в ядре с бо́льшим количеством нуклонов их больше, нам придётся считать их массу отрицательной. Другое дело, что вовсе не факт, что их больше в бо́льшем ядре. Но речь шла не об этом, и не хочется в таки дебри уходить, тем более что там можно только спекулировать. «Теорию всего» мы всё равно в рамках этого треда не придумаем.

У меня для тебя плохие новости…

Отобрали взад уже

Никак нет, зашёл на почту, вижу «Занято 206 ГБ из 1 ТБ». Другое дело, что без WebDav'а этот терабайта напоминает басню Крылова «Лиса и журавль», но это уже другой вопрос

У меня для тебя

Уже не у тебя и уже не для меня

Никак нет, зашёл на почту, вижу «Занято 206 ГБ из 1 ТБ».

Вот говноеды, у меня стало 8Гб :(

Не умничай. Запутаешься же сам если начнёшь пытаться свести ту теорию, на которую ты намекаешь, с дословной «суммой масс частиц». Даже на более простом примере с электронами.

Не умничай.

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

Хотя нет, я раньше начал умничать, когда сказал про то, что вес не равен массе.

Хотя нет, это он раньше начал умничать, когда придумал эти железо с пёрьями, когда речь про байты.

Хотя нет…

….

:)

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

Вероятность коллизии крайне низка. При этом если она возникнет, то яндексу ничего не будет — ну извинятся перед пользователем, ну даже если он потеряет там условный миллион-другой — заплатят.

Да нет же, речь не об этом. Понятно, что несколько отдельных случаев никто даже не заметит. Появились SHAttered PDFs – их хэши внесли в исключения и поехали дальше.

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

не берусь утверждать, насколько значительная

А я возьмусь. Эта часть - 100%. (ладно, если исключить предварительно безопасно пошаренные ключи шифрования, но такое крайне редко используется)

У нас часть криптографии (не берусь утверждать, насколько значительная) держится лишь на сложности тех или иных вычислений

Да в принципе практически вся, что не базируется на одноразовых блокнотах. Всё, что приватный+публичный ключ — именно на этом держится. А это очень, очень значительная часть применяемой на практике криптографии.

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

Запутаешься же сам если начнёшь пытаться свести ту теорию

Путаница как раз том, что ты делишь ядро на «классические» частицы. Реакция деления ядра - это не арифметическое деление. То что после такой реакции получаются некие стабильные «классические» частицы, не означает, что ядро состоит из этих частиц.

Да нет же, речь не об этом.

Да как раз об этом. Цена «ошибки» vs вероятность оной. Нет смысла вкладываться в то, что очень дёшево (при умножении вероятности ошибки на её цену) стоит. Ни яндексу ни сотням других компаний, которые действуют так же.

Но что если коллизий будет много, причем для кучи случайных значений хэша?

А что если на главный офис завтра упадёт метеорит?

Слишком малая вероятность. Особенно слишком малая вероятность, что внезапно будет много. И совсем малая, что внезапно станет много сразу по двум алгоритмам. Это надо, чтобы кто-то придум способ генерации соответствующего файла для одного алгоритма, затем никому не говорил, что оно уже есть, и придумал для другого. Вероятность такого оценщики рисков оценят очень близко к нулю. Реально вероятнее, что принимающему решение прилетит случайная частица высокой энергии, и он умрёшь по необъяснимой причине, чем что будет именно так.

Никто не будет всерьёз закладываться на такие риски.

Оценка рисков вообще важная часть бизнеса. Стоит понимать, хотя бы в общих чертах, как это делается.

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

А вот это здравая мысль. И поэтому хорошо, что алгоритмов разных у нас много. И в целом я всегда топлю за «зоопарк» и искрене недоумеваю, почему так многие видят в нём не просто проблему вместо, но и проблему важнейшую, ради искоренения которой и приведения мира к «1 народ, 1 рейх, и т.д.», стоит многим жертвовать…

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

Слишком малая вероятность.

Т.е. вам известна вероятность рождения супер-Перельмана в следующем году? Ну хотя бы по порядку величины? Более того, алгоритм может создать даже не человек, а просто забагованный комплятор для ПЛИС, перебирая различные комбинации вентилей… (тут мои фантазии на тему терминологии).

А что если на главный офис завтра упадёт метеорит?

Упадет метерорит — минус офис. Будет генератор коллизий — минус ВВП человечества.

Т.е. вам известна вероятность рождения супер-Перельмана в следующем году? Ну хотя бы по порядку величины?

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

Более того, как и многие данные в бизнес-логике, есть вещи, которые не известны и не могут быть известны, но предполагаются.

Предположения основаны на уверенности.

А уверенность человека в том или ином предположении в свою очередь можно оценить вполне экпериментальным способом — какую сумму он готов поставить на это при условии, что если он прав, он получит вдвое больше, а если неправ, то потерят ставку (там можно сложнее, но это простейшее).

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

Если хочешь именно вероятность, то она мне, естественно не известна. Но я очень осторожно оценю её как «не выше, чем 10⁻¹²», хотя склоняюсь скорее к «не выше, чем 10⁻¹⁹», но ставить на такую вероятность бы не стал (а под -12 поставил бы любую сумму).

Упадет метерорит — минус офис. Будет генератор коллизий — минус ВВП человечества.

Конкретному Яндексу (Гуглу, любому другому), а ещё точнее, человеку, который принимает там решения на этот счёт, плевать на ВВП человечества. Он отвечает конкретно за свою сферу.

Нормально тут обсуждение физики с участием модератора.

По теме треда хотел спросить, rclone для Яндекс диска кто-то использует? Думаю как проще сделать, rclone + restic или что-то более модное есть.

использую. бекап хлама в яндек-диск. работает.

Просто rclone, или что-то поверх?

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

Вебдав появляется при покупке любого минимального тарифа. Так что покупаешь типа 64ГБ а получаешь честный davfs на весь терабайт. Проверено.

А вдруг коллизии?

«Сервис предоставляется как есть, без гарантии применимости и ответственность предоставляющего сервис ограничивается абонентской платой за один месяц». И теперь коллизия это проблема клиента!

...закинуть с компа в облако музыкальный альбом...

Ну ССЗБ.

...как оно вылетело в облако за 5 сек, если при моих скоростях это должно было занять минут 20, а скорее всего и дольше? Что за магия?

Символические ссылки кидает.

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

Скопировал перетаскиванием … И тут вжух и почти сразу показывает 100%

Непонятно, откуда Диск узнал контрольную сумму, не получая файл полностью? особенно, если «перетаскивание» это в web версию Диска.

Вероятность коллизии крайне низка.

Точно, именно такой развёрнутый ответ хотелось бы написать. Мало того что коллизии низка, так ещё и коллизии будет иметь такой набор бинарных данных, который будет выглядеть как мусор. То есть нормальный человек выложив осмысленный файл с вероятностью 0% получит коллизию с другим осмысленным файлом.

начал умничать

Когда для дела, это не умничать, а когда отойти от темы чтобы…, то это уже умничать.

который будет иметь коллизию с произвольным заданным по двум разным алгоритмам подсчёта хэша.

Учитывая увеличение длины SHA он вполне мог бы заложить в алгоритм длину байтов и какой нибудь CRC32. А может его алгоритм настолько стойкий к отсутствию коллизий, что его последняя версия превышает предыдущую версию с +размер +CRC32.

Непонятно, откуда Диск узнал контрольную сумму, не получая файл полностью? особенно, если «перетаскивание» это в web версию Диска.

А что, скрипт теперь не может получить хеш файла?
А теперь гуглим: «может ли джава скрипт получить хеш файла».
Ответ ИИ: Да, JavaScript может получить хеш файла как в браузере.

погугли :) мат.выкладок по использованию хэш-идентичности файлов было дохрена.
из прикладных использований смотри торрент и подобные п2п системы. там аккурат файл получают по его хешу :)

Может быть может, но не делает, проверил сейчас просто загрузкой файла который есть в другом месте и на предложенном тут выше linux-6.18.9.tar.xz, загружает полностью. Наверно, не очень безопасно со стороны открытого клиента доверять полученному от него хешу, так не далеко до получения доступа к чужим файлам)

погугли :) мат.выкладок по использованию хэш-идентичности файлов было дохрена.

гугл запрос: много ли коллизий SHA256 ответ ИИ: Нет, коллизий (ситуаций, когда разные входные данные дают одинаковый хеш) у SHA-256 практически нет. Хотя теоретически из-за бесконечного числа входов и конечного числа выходов ((2^{256})) коллизии существуют, вероятность их случайного обнаружения астрономически мала ((1) к (2^{256}) или (\approx 1.2\times 10^{77})), что делает алгоритм на данный момент надежно защищенным

и чё ?? не хватит ответа всеразумного ИИ ?? :)
ну для хеширования криптографической стокйоксти не требуется. смотри какие алгориты используют в пиринговых сетях.

Они считают хеш на клиенте до загрузки и на сервере после загрузки.

смотри какие алгориты используют в пиринговых сетях.

Ну в bittorrent, кстати, не один хэш на весь файл, а по 20 байт на piece. Piece size задаётся при создании торрент-файла — его можно вручную задать, но вообще большинство создавалок автоматически делает piece size примерно в 1000 раз меньше объёма данных, то есть для 8-гигабайтного торрента будет piece size 8 МБ (он должен степенью двойки бы, да), и вот на каждый 8 МБ своя контрольная сумма.

ну для хеширования криптографической стокйоксти не требуется

Почему ты думаешь, что защищенный подразумевается криптографическая, а не от коллизий.

то что битторент не привязался к файлам это бооооольшой минус :) однако в любом случае последний piece раздачи все равно будет произвольной длины.
и вся раздача подписывается одним хешом, по которому его можно однозначно найти, используя магнит-ссылкой к примеру magnet:?xt=urn:btih:4a984ee35f1f09e95e50c224ab70b775a43e8e06

@AZJIO требования для криптографической стойкости другие.

то что битторент не привязался к файлам это бооооольшой минус :)

исправили же в v2, то что ей мало желающих пользоваться, не важно )

можно однозначно найти

или не найти, если никто не соизволил вещать этот хеш в dht

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

Симметричная криптография сама по себе практически нигде не применяется. Ей в подавляющем большинстве случаев предшествует асимметрично-криптографическое согласование ключей.

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

Моего желания недостаточно? А прошу чего-то аморального или противозаконного?

Нет, недостаточно.

Понимаешь, Диск - он не твой, он Ядекса. Там прямо написано в названии сервиса - Яндекс Диск, что б ты не забывал.

Так вот, работать он будет так, как хочет Яндекс, в широком смысле, а в узком - как его напрограммировали программисты Яндекса на инфраструктуре Яндекса по тикетам продактов Яндекса в соответствии с идеями руководителя сервиса Яндекса. Так вот, если там решили, что контент (в Эллиптиксе или что там ему на замену пришло) надо хранить на ключе, который является SHA256 от содержимого файла (или rolling hash, как пойдёт) потому, что это хорошо дедублицирует пиратский контент, то тебя, конечно, не спросят. У этого решения нет недостатков, одни достоинства.

Симметричная криптография сама по себе практически нигде не применяется.

упрлс что ли?

не знаю, почитай про semantic security, что ли.

я в курсе, а хеш считается взломанным если научились находить любую из них

чел, ты не отличаешь preimage, от second preimage и от collision, а лезешь что-то комментировать про криптографию.

я, пожалуй, не буду больше комментировать, воспользуюсь советом Марка Твена о спорах.

Прекращай нести чушь с умным видом.

1) Не вздумай отрицать что 99%+ всех «шифровок» идут через согласованные всякими DH-подобными алгоритмами ключи. От того что где-то полтора анонимуса пользуются чем-то другим - оно подавляющим меньшинством быть не перестаёт.

2) При чём тут отличение этого всего? Есть preimage = хэш взломан, из использования (во всех разумных местах) выводится. От preimage спасает только сложность вычислений.

v2 не взлетело :( поздно слишком запустили.

тут тема в другом. вся раздача подписывается одним хешом, и я ни разу не слышал чтобы в битторенте находили коллизии (хотя и не искал это специально).
следственно 20 байтного хеша хватает для прикладного использования в качестве уникального идентификатора файла :)
интересно какой ключ в я.д используют для идентификации файла.

Моего желания недостаточно? А прошу чего-то аморального или противозаконного?

Однозначно. Для всех идиотов с их идиотскими желаниями есть свой индивидуальный хостинг со своими идиотскими алгоритмами.

Там вроде как на многие хеши известны атаки. Так что можно вирусню и прочее говно вот так подсовывать. Да, довольно дорогое удовольствие, например, на то чтоб sha1 pdf сделать файл с другим содержимым (при том того же размера и конкретным визуальным содержимым, манипулируя мусором у спецов из гугла вроде как месяц ушел на обычном хорошем компе, тех времён, когда sha1 был ещё актуален). Но я думаю месяц можно позволить себе потратить, чтоб яндекс сам распространял ботнет среди своих юзеров.

Но я думаю месяц можно позволить себе потратить, чтоб яндекс сам распространял ботнет среди своих юзеров.

Для этого придётся узнать, какие именно алгоритмы рассчёта хэшей используются. А ещё может в каждом случае использоваться соль, и её тоже надо будет угадать/подделать.

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

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

зачем ковырять ?? яндекс апи диска открыто выкладывал.

Хм… Ну тогда смотреть надо. Не факт, что фича с кэшами работает через API тоже, может быть только через их клиент.

Где посмотреть документацию по API?

upd: https://yandex.ru/dev/disk/

upd2: Да, похоже тупо md5: https://github.com/yandex-disk/yandex-disk-sdk-java/blob/master/yandex-disk-sdk/src/com/yandex/disk/client/TransportClient.java#L554

А нет, ещё sha256.

Короче, само по себе всё довольно просто. Но придётся генерировать файл заданного размера, у которого с целевым совпадает и md5 и sha256. А это кратно более ресурсоёмко, чем только sha256. Я сомневаюсь, что получится сделать это для произвольного файла за месяц, да и за год тоже.