Может ли файл быть злонамеренно изменен таким образом, чтобы сохранить исходный хэш SHA-1?

Никто еще не достиг этого для SHA-1. Это возможно в теории, но все еще не практично. Отчеты о небезопасности в SHA-1 просто означают, что уровень безопасности не так высок, как нам хотелось бы, и это означает, что у нас не так много лет, чтобы думать об этом, как мы думали.

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

Это теоретически возможно, но это еще не сделано.

То, что вы ищете, называется «коллизия хешей»: два файла с одинаковым хешем. Криптографические хэш-коды, такие как SHA-1, обычно предназначены для того, чтобы сделать это трудным. Поскольку SHA-1 является 160-битным кодом, в среднем потребуется 2 ^ 159 попыток перебора, чтобы найти дубликат. Если найден алгоритм, который надежно работает лучше, чем алгоритм против криптографического хэша, хеш считается «сломанным».

MD-5 - пример очень сломанного хэша. Он должен был иметь прочность 128 бит, что требовало в среднем 2 ^ 127 попыток. Как и в случае злоупотребления известными уязвимостями, фактическое количество попыток может достигать 2 ^ 47. Это много меньше, чем 2 ^ 127. Фактически, это было сделано менее чем за один день на современном вычислительном кластере.

Я привожу этот пример, потому что это наиболее близко к тому, как вы собираетесь использовать SHA-1. Тем не менее, это не самый распространенный подход криптоанализа для проверки того, что хэши не сломаны. Они обычно допускают конфликт между двумя файлами, выбранными злоумышленником, вместо того, чтобы вы выбирали один файл и злоумышленник пытался сопоставить его. Преимущество такого рода атак состоит в том, что их легче сравнивать. Если я нахожу, что «тяжело» взломать ваш файл, значит ли это, что другой файл такой же сильный? Эта атака, при которой злоумышленник выбирает оба файла, гарантирует, что мы поймаем худшее из худшего.

Этот тип атаки позволяет использовать интересный трюк, известный как « атака на день рождения ». Короче говоря, использование атаки на день рождения вдвое снижает эффективность алгоритма, поэтому SHA-1 требует в среднем 2 ^ 80 попыток, а MD5 требует в среднем 2 ^ 64 попыток. Это половина из 160 и 128 соответственно.

SHA-1 имеет известные атаки, которые уменьшают свою силу с 2 ^ 80 до 2 ^ 69. Это не будет иметь большого значения для вас. 2 ^ 69 попыток это долго .

Однако из истории мы обнаружили, что алгоритмы хеширования не нарушаются самопроизвольно, а скорее нарушаются со временем. Никто не взломает алгоритм, подобный MD-5, взяв его с 2 ^ 64 до 2 ^ 47 за ночь. Это происходит со временем, так как многие люди публикуют статьи о математике, которую они используют против нее. Обычно можно наблюдать, как сложность атак медленно снижается с самого начала алгоритма (где лучшая атака обычно - атака на день рождения).

Тот факт, что мы видим некоторые изменения в столкновениях, предполагает, что SHA-1 видит свет в конце туннеля. Он по-прежнему силен, но может возникнуть желание перейти на новейший SHA-3, который в настоящее время намного безопаснее.

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

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

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

Для файлов такая же ситуация не всегда применима. Если вы обеспокоены тем, что создатель файла является злоумышленником (например, он получит одну вещь независимо проверенную как хорошую, а затем отправит вам вредоносную информацию с тем же хешем), применяется атака SHA-1, и вы должны посмотреть к постепенному отказу от этого (хотя это еще не критично, как упоминал Дэвид Шварц). Если исходный файл является доверенным, то злоумышленник не может применить известные на данный момент атаки SHA-1, хотя вам все равно следует подумать о его поэтапном отказе, если можете (если у вас есть выбор, используйте хэш без известных атак, таких как SHA- 2).

В ответ на «столкновение не будет полезным» - хотя атака не требует от злоумышленника возможности получить полезное столкновение, обычно не так сложно превратить «столкновение» в «полезное столкновение». Многие форматы файлов имеют достаточно места, в котором вы можете иметь все, что захотите, не влияя на функциональность файла; злоумышленник обычно может изменить это, чтобы получить столкновение (если столкновения практически обнаруживаются), сохраняя при этом функциональную часть в том виде, в каком он хочет. Разрыв между «академической атакой» и «практической атакой» может быть большим; разрыв между «любым столкновением» и «полезным столкновением» обычно намного меньше.

Более серьезная проблема, которая не связана с выбором алгоритма, заключается в том, как вы получаете хэш. Все, что делает хеш - это смещает проблему с «получить реальный файл» на «получить реальное значение хеша»; хеш-значение, отправленное с того же сервера и с тем же типом соединения, что и файл, совершенно бесполезно против злонамеренной модификации (любой злоумышленник, который может подделать файл, может подделать хеш). Хэши полезны только для этого, если вы можете доверять хешу больше, чем файлу; хотя иногда это так (торренты, зеркала), они часто используются, когда это не так. Поэтому вы должны быть очень осторожны с этим всякий раз, когда используете хеши для проверки целостности.

You have to differentiate between a collision attack and a preimage attack. Finding any two messages that hash to the same value is a collision attack.
Replacing one particular, given message (here: an executable) with another message that has the same hash is a (second) preimage attack.

SHA-1 is broken insofar as a collision attack can be done in 2⁵² operations according to a Wikipedia article that does not provide a citation for that number (the best attack that I am aware of which is actually credible is the one by Marc Stevens, which takes 2⁶⁰ operations). But let's assume the pessimistic case of 2⁵².

This is concerning because an attack at that scale is not only theoretically conceivable but indeed perfectly doable in under a day on a multi-GPU rig. That's of course a problem for applications where "any two" messages will do. Even the 2⁶⁰ figure given by Stevens (which is 256 times more work) is perfectly feasible if your attacker is willing to throw some extra money at the problem, or is willing to spend a year of time.
Which is exactly the kind of thing that won't prevent someone involved in espionage or cyber crime from forging certificates.

Now, a preimage attack has an exponent that is twice as large, so assuming 2⁵² for the collision attack, that would be 2¹⁰⁴ operations, which is a totally different ballpark.

This is not only impractical (a machine that is a billion times faster than the one mentioned in the previous paragraph would still take around 6 million or so years), but given our puny means of generating energy this is entirely impossible.

Doing such a massive calculation would require an energy source which is much larger than anything we can afford to dedicate to a single operation. No, not quite an energy source the size of the sun, but still a quite big one.

You can realistically expect to get anything from 10 to 50 GFLOPS out of one Watt. Assuming that some kind of miracle happens and processors get about several thousand times more energy efficient over night, one could assume 1 SHA ≈ 1 FLOP (quite optimistic!). This would mean that in order to perform 2¹⁰⁴ hash calculations within 10 years, you need a 10¹²W power plant. In order to run the attack within 1 year, you need a 10¹³W power plant. That's about 50 times of what the entire nuclear power plants of the USA, France, and Japan can produce together, only for forging a single hash.

This is not going to happen, there are much easier ways of achieving the same goal (exploiting the server that stores the original hash and replacing that one, blackmailing someone, etc.).

Общая точка статьи refered в вопросе: SHA1 является устаревшим и должно быть прекращено, пока еще есть время, чтобы сделать это плавно. В некоторых областях время истекает, поскольку Google и Microsoft соблюдают крайние сроки.

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

• Если вы делаете новый дизайн или добавляете функции, не используйте его (SHA1).
• Если вы поддерживаете что-то старое, составьте план, когда его заменить (SHA1).

Краткая цитата из сообщения в блоге 2012 года Брюса Шнайера: «Дело в том, что мы в сообществе должны начать переход от SHA-1 к SHA-2 / SHA-3 сейчас».

For the SHA-1 hash collision part of your question, this has been addressed by a few of the answers.

However, a big portion of this hinges on the type of file we're working with:

Maintains the file's overall content and operation (but of course now includes malicious content that was not originally there changed contents)

What this means varies greatly on what is detecting the alterations:

• If it's a signed executable, not a (reasonable) chance: you'd have to get two hash collisions somehow: the SHA-1 of the file and the internal .exe signature.
• If it's an unsigned executable, .com, unsigned .dll, or similar, their resource forks can be added to in ways that will not change their operation and thus you could (eventually) get a hash collision that is not detectable by 'normal' operation.
• If it's a source code file or similar structure (.cs, .c, .h, .cpp, .rb, .yml, .config, .xml, .pl, .bat, .ini) the additions, modifications, or removals can be constrained to valid comment syntax such that the change would not be discernible by most uses (compiling or running it, not opening it up with a text editor).
• If it's an .iso or .zip or other container format, it is also more unlikely since most random changes will corrupt the container. It is possible to do: add a bogus file entry or alter a content within the container and recheck it, but you're adding a layer of complexity and adding additional time to check the result, as well as having limited degrees of freedom with respect to how and what contents may be changed.
• If it's a text or text-like format, they can be changed almost any way you like while still being a 'valid' file, though the content will probably be noticeable.
• With many formats like .rtf, .doc, .html, .xslx, and other markup-esque formats, they can be added or modified in ways that will be undetectable by parsers, so other than the length (or even with a constrained length, less freedom) the files can be altered to (eventually) get a hash collision while still being not only a valid file, but not noticeably changed in any way that would be visible to the typical applications they would be used with.

So, what you're left with is how to get collisions in whatever structure that is noncorrupting and some degree of undetectable perhaps:

1. Make any functional changes you desire (perhaps insertion of malicious content) and make any additional changes to retain file format specific validity
2. Add a section that will be non-functional (between comment blocks, at the very end of a text file with 3k carriage returns above it, isolate a current comment block)
3. Add or select a character/code point/byte for modification and try every possible valid combination (not every byte combination is valid for different encodings, for example).
4. Recompute the hash, see if collision matches.
5. if it does not, goto 3.

Let's say you have a super fast computer and a smallish file, such that modification with a valid byte sequence and recomputing the hash takes 1 millisecond (probably requiring some dedicated hardware). If the hash distribution is perfectly random and distributed across the range, you will get a collision with SHA-1 every 2^160 attempts (brute forcing it).

2^160/1000/60/60/24/365.24 = 4.63x10^37 years = 46,300,000,000,000,000,000,000,000,000,000,000,000 years = 46 undecillion years. 

But hey, let's try the 2^60 and 2^52 versions, and pretend that they allow us to modify the file any way we like (they don't) and that they, too, can be done in 1ms each try:

2^52 yields 142,714 years /*humans might still be around to care, but not about these antiquated formats*/ 2^60 yields 3.65x10^7 years = 36,500,000 years /*machines will probably have taken over anyway*/ 

But hey, you might get lucky. Really, really, more-of-a-miracle-than-anything-people-call-miracles lucky.

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

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

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