Если на планете не будет больших залежей скафандров и оборудования (достаточных чтобы возможность их прогрызать дала эволюционное преимущество) то вряд ли
Кроме того даже если и вдруг случится такое, все равно будет лучше чем то что сейчас там. Поменять материал из которых делают скафандры не проблема. Вода и воздух неплохо уничтожают большое количество химических соединений — ну так такие просто не используются в строительстве.
Все структуры данных (стеки, очереди, хешмапы, ...) используют linked list как деталь реализации
Если привязываться к языку то можете посмотреть реализацию в c# или java ConcurrentЧтоУгодно
Причина в том что lock-free фактчиески строится на одной команде cpu CAS https://en.wikipedia.org/wiki/Compare-and-swap
и это значит что мы можем поддерживать связный список в консистентном состоянии следующим образом:
прочитать значение по указателю
сделать операцию иммутабельным образом над значением по указателю (классическим методом)
при помощи CAS заменить указатель на старый объект на новый. Если не получилось (кто-то другой влез перед нами), goto шаг 1.
Так 2^64 или 2000 итераций нужно, чтобы наткнуться на коллизию? Вы уж определитесь. :)
Это совсем разные итерации. Прочитайте переписку еще раз.
при вычислении 2^64 отдельных md5 есть заметный шанс наткнуться на одну коллизию
Самодельная функции md5^2000 скорее всего более слабая чем прсто md5 даже учитывая в 2000 раз большее время вычисления. Все предпосылки для этого есть. Это не доказано, но в криптографии нужно доказывать то что что-то работает, а не то что не работает.
Почему вы думаете, что «хэш3+хвост» аннулирует предыдущую коллизию? Хвост-то у нас константный.
потому что hash(collision+pass1) != hash(collision+pass2) потому что pass1 != pass2
"хвост" это пароль. Пароли разные. Нет "хвоста", есть хвост1 и хвост2.
Если бы 5% хэшей совпадали, достаточно было бы высчитать пару миллионов хэшей и сравнить их между собой
Разумеется нет. Если есть 5% шанс найти коллизию из 340282366920938463463374607431768211455 то это не значит что есть 5% шанс найти коллизию из миллиона.
Однако, из-за парадокса дней рождений, если высчитать 2^(128/2) хешей то вероятность найти одну коллизию уже заметно отлична от 0.
2^64 это, впрочем, пока еще дофига, и это мало что даст.
Здрасьте. А куда она денется?
Что такое коллизия?
Это когда два разных пароля дают одинаковый хеш.
Если на этапе N получлась коллизия, то на этапе N+1 она пропадет, потому что пароли-то разные, а они примешиваются на каждом этапе. В отличии от md5(md5(...))
Если 5% хэшей совпадают, то это очень некачественная функция. Даже в MD5 такого количества коллизий нет.
Есть ссылки на какие-то исследования по этому? Мне кажется там даже больше.
На минуточку, мое утверждение значит что "для любого хеша есть 5% шанс что один из оставшихся 340282366920938463463374607431768211455 хешей совпадет". Кажется что там даже больше из-за парадокса дней рождения.
Вы только что обозвали дураками разработчиков PBKDF2 — они там как раз тем и занимаются, что используют много раундов хэширования для генерации ключей шифрования.
Если прочитать внимательнее мое сообщение то можно оттуда увидеть причину проблемы многоразового хеширования. Причина в том что если на каком-то этапе будет коллизия, то эта коллизия сохранится до конца хеширования. И чем больше раундов, тем больше шансов что она произойдет, ослабляя итоговую функцию.
Это НЕ так для PBKDF2. Потому что они на каждом раунде примешивают пароль. То есть даже если на каком-то раунде будет коллизия, она перестанет быть коллизией на следующем.
Именно из-за таких нюансов и существует совет "не изобретать самому ничего в криптографии" (вроде md5(md5(md5(...))) а пользоваться проверенными решениями (вроде PBKDF2)
Их не будет исчезающе мало. Хеш функции специально не проектируются для такой цели
Может быть некоторые хеш-функции обладают таким свойством, также можно специально создать подобную хеш функцию, но вообще это не является требованием.
Их, конечно, будет не много. Но не исчезающе мало.
Возьмем с потолка 5%. То есть при хешировании всех 2^128 хешей, 5% из них совпадут.
Тогда при хешировании 2000 раз останется лишь (опять же с потолка) 2^128 * (0.95)^2000 и результат будет <1. То есть вообще возможна ситуация что при применении хеша 2000 раз результат будет всегда одинаковый.
Это, конечное же, в реальности не произойдет. Потому что на самом деле на каждой итерации совпадать будут все меньше и меньше хешей. Но ослабить таким образом используемую хеш функцию до уровня "слабее чем 1 хеширование" можно запросто, даже с учетом х2000 времени вычисления каждого хеша.
Я когда тулзу для игрушки делал сделал темную тему (хоть и с светлой по умолчанию) потому что игрушка относительно темная да и играют зачастую в темноте :)
Насчет шифрования не уверен но для вычисления хешей это точно так. При вычислении хеша есть шанс коллизии, и при вычислении хешей несколько раз шанс коллизии растет.
т.е. условно md5(md5(plaintext)) может быть менее секьюрно чем md5(plaintext)
Во-первых, чтобы поднять орбиту надо добавить импульс в сторону движения, чтобы снизить — назад. При этом изменение скорости относительно орбитальной будет незначительное.
Во-вторых, необходимо иметь очень низкую относительную скорость. А это значит что объект с мусором и так уже на одной орбите был.
Можно на электронное табло на вокзалах
На земле миллионы (миллиарды?) видов и даже то что нашелся один который кое-как разлагает пластик все равно не мешает пользоваться пластиком.
Поэтому и написал "вряд ли"
Если на планете не будет больших залежей скафандров и оборудования (достаточных чтобы возможность их прогрызать дала эволюционное преимущество) то вряд ли
Кроме того даже если и вдруг случится такое, все равно будет лучше чем то что сейчас там. Поменять материал из которых делают скафандры не проблема. Вода и воздух неплохо уничтожают большое количество химических соединений — ну так такие просто не используются в строительстве.
Тогда и все жс состояние нужно держать. Может быть накладно и не всегда вообще возможно
Можно использовать энергию напрямую — пожарить яичницу например
Если не привязываться к конкретному языку программирования то вот что нагуглилось
https://www.cs.tau.ac.il/~shanir/concurrent-data-structures.pdf
Все структуры данных (стеки, очереди, хешмапы, ...) используют linked list как деталь реализации
Если привязываться к языку то можете посмотреть реализацию в c# или java ConcurrentЧтоУгодно
Причина в том что lock-free фактчиески строится на одной команде cpu CAS https://en.wikipedia.org/wiki/Compare-and-swap
и это значит что мы можем поддерживать связный список в консистентном состоянии следующим образом:
Да и сейчас можем только узкий диапазон атомных масс и все изотопы — нестабильны. Про другие изотопы есть только теоретические значения параметров.
Если есть возможность читать любую память то ничто не мешает просто ходить по указателям
Это совсем разные итерации. Прочитайте переписку еще раз.
потому что hash(collision+pass1) != hash(collision+pass2) потому что pass1 != pass2
"хвост" это пароль. Пароли разные. Нет "хвоста", есть хвост1 и хвост2.
Разумеется нет. Если есть 5% шанс найти коллизию из 340282366920938463463374607431768211455 то это не значит что есть 5% шанс найти коллизию из миллиона.
Однако, из-за парадокса дней рождений, если высчитать 2^(128/2) хешей то вероятность найти одну коллизию уже заметно отлична от 0.
2^64 это, впрочем, пока еще дофига, и это мало что даст.
Что такое коллизия?
Это когда два разных пароля дают одинаковый хеш.
Если на этапе N получлась коллизия, то на этапе N+1 она пропадет, потому что пароли-то разные, а они примешиваются на каждом этапе. В отличии от md5(md5(...))
Есть ссылки на какие-то исследования по этому? Мне кажется там даже больше.
На минуточку, мое утверждение значит что "для любого хеша есть 5% шанс что один из оставшихся 340282366920938463463374607431768211455 хешей совпадет". Кажется что там даже больше из-за парадокса дней рождения.
Если прочитать внимательнее мое сообщение то можно оттуда увидеть причину проблемы многоразового хеширования. Причина в том что если на каком-то этапе будет коллизия, то эта коллизия сохранится до конца хеширования. И чем больше раундов, тем больше шансов что она произойдет, ослабляя итоговую функцию.
Это НЕ так для PBKDF2. Потому что они на каждом раунде примешивают пароль. То есть даже если на каком-то раунде будет коллизия, она перестанет быть коллизией на следующем.
Именно из-за таких нюансов и существует совет "не изобретать самому ничего в криптографии" (вроде md5(md5(md5(...))) а пользоваться проверенными решениями (вроде PBKDF2)
Их не будет исчезающе мало. Хеш функции специально не проектируются для такой цели
Может быть некоторые хеш-функции обладают таким свойством, также можно специально создать подобную хеш функцию, но вообще это не является требованием.
Их, конечно, будет не много. Но не исчезающе мало.
Возьмем с потолка 5%. То есть при хешировании всех 2^128 хешей, 5% из них совпадут.
Тогда при хешировании 2000 раз останется лишь (опять же с потолка) 2^128 * (0.95)^2000 и результат будет <1. То есть вообще возможна ситуация что при применении хеша 2000 раз результат будет всегда одинаковый.
Это, конечное же, в реальности не произойдет. Потому что на самом деле на каждой итерации совпадать будут все меньше и меньше хешей. Но ослабить таким образом используемую хеш функцию до уровня "слабее чем 1 хеширование" можно запросто, даже с учетом х2000 времени вычисления каждого хеша.
Когда пишешь какие-нибудь lock-free алгоритмы. Там односвязные списки практически единственное что можно использовать.
Я когда тулзу для игрушки делал сделал темную тему (хоть и с светлой по умолчанию) потому что игрушка относительно темная да и играют зачастую в темноте :)
По цене недорогих bluetooth наушников :)
Или поисковый краулер забрел в админку и начал переходить там по всем ссылкам
Насчет шифрования не уверен но для вычисления хешей это точно так. При вычислении хеша есть шанс коллизии, и при вычислении хешей несколько раз шанс коллизии растет.
т.е. условно md5(md5(plaintext)) может быть менее секьюрно чем md5(plaintext)
Также была не упомянута проблема грабежей, насилия, терроризма, военных преступлений и защиты прав человека.
Орбитальная механика так не работает.
Во-первых, чтобы поднять орбиту надо добавить импульс в сторону движения, чтобы снизить — назад. При этом изменение скорости относительно орбитальной будет незначительное.
Во-вторых, необходимо иметь очень низкую относительную скорость. А это значит что объект с мусором и так уже на одной орбите был.
Большой бинарный BLOB-объект!