Плюс нередко приходится переучивать на новый софт пользователей.
Переучивать приходится если начали работать с закрытым решением, а потом его у вас отобрали (лицензии больше не продают, государство запретило, производитель прекратил поддержку, мало ли причин).
А если вы сразу начали с OSS решений, то переучивать никого не надо. И отобрать их сильно сложнее.
... задолго до появления компьютеров. Ваш баланс в банке раньше считали и хранили на бумажке. Окей, деньги можно было не хранить в банке, но резаной бумагой они от этого быть не перестанут. Вся их ценность только в том что другие люди тоже верят в их ценность.
Или вот паспорт. Вы сколько угодно можете доказывать что вы подданный Британской Короны но без паспорта вам не поверят.
Вы можете выглядеть хоть на 90 лет, но если вы не покажете пенсионное свидетельство то вам могут отказать в бесплатном проезде.
Вы можете хоть обхаркать кровью весь отдел кадров, но без больничного у вас будут больше проблемы, если вас неделю не было на работе.
Если у вас есть каперское свидетельство - вы можете безнаказано брать на абордаж корабли. Если нет - ну значит нет, добро пожаловать на виселицу.
Я немного далек от это области, поэтому возможно не совсем понимаю... Зачем хранить сгенерированный код в репозитории? Он же генерируется.
В наших проектах мы тоже используем генерацию кода, я подозреваю что любой более-менее большой проект страдает этим. Но зачем же запихивать то что сгенерировали в гит? Билд система должна (пере-)генерировать эти файлы локально. А то мы так дойдем до того, что еще и объектные файлы в гите держать будем...
Откуда вы знаете? На картинке нарисованы линии. Возможно - эти линии - это проекция трехмерного объекта на двумерную плоскость. А возможно - просто линии.
Почему "моя перспектива"? Это же вы написали про смежника который провалил сроки. Теперь вы пытаетесь сказать что это уже не "смертельно опасно"? Или как понимать ваши слова?
А если сроки провалите вы? Это только в кино к вам с фронта притаскивают доктора всех наук, который все знает и все делает за две недели.
А вот если нет такого человека? А вам поручили... ну например разработать жаропрочный сплав для лопаток в турбине. Вы попробовали 100 разных вариантов, вроде бы нащупали закономерность но надо еще полгода чтобы получить финальный результат. Вот только к вам уже стучатся люди в коже и ведут в машину с надписью ХЛЕБ. Потому что вы провалили сроки, результата нет, Берия недоволен. Как вам такая перспектива?
Вот этого я не знаю. Но у них там есть два датума. Один вот этот вот со смещениями, а второй - нормальный. Возможно для работы с кадастром они используют второй датум.
Я ниже писал про ЧПУ станки и мне там же написали что даже полиграфическое оборудование имеет схожие ограничения. Думать что Никона с Кэноном не будет такой же фигни - несколько наивно.
(В конце концов, литограф - это же такой полиграфический станок с очень мелким размером отпечатка /s).
Офигеть новость. Некоторые CNC станки блокируются если их просто перенести в соседний цех. А если их перевести в другую страну - они в принципе не будут работать. И все об этом знают.
На счёт "фокуса с XOR" - никогда о таком не слышал... То есть, злоумышленник может собрать, например, кучу файлов, зашифрованных одним и тем же подобным алгоритмом, да ещё и одним ключом, и как-то получить что-то типа корреляции?
Нет, все куда проще. Вы же шифруете вот так ciper=HASH(mainkey + chunkid) XOR plain.Допустим у у нас есть два заширфованных текста: С1 = HASH(mainkey + chunkid) XOR plain1 и С2 = HASH(mainkey + chunkid) XOR plain2.
Делаем C1 XOR C2 и получаем plain1 XOR plain2 потому что часть с HASH() сократится. Анализировать plain1 XOR plain2 уже намного проще, особенно если можно набрать несколько таких пар. Но в любом случае на этом моменте шифр уже сломан.
Получается, что нули - главный враг XOR'а, ведь просто просвечивают ключ...
Именно! Но если у вас гамма-последовательность каждый раз разная (благодаря случайным IV), то это уже не проблема.
Значит, можно заменить номер чанка на соответствующий элемент какой-нибудь псевдослучайной последовательности + IV?
ну можно и так. Но лучше считать HASH(mainkey + IV + chunkid) , символ + тут - это конкатенация, а не арифметическое сложение, если что.
А от чего брать IV, чтобы при расшифровке проблем не было?
А его надо хранить. При шифровании генерируете 16 случайных байт и кладете их в самое начало файла, например. Или в конец. Их не надо никак шифровать или прятать. Главное требование - вектор должен быть разным каждый раз. И пофиг что его всем видно. При расшифровке, соответственно сначала читаете IV, потом уже основной шифропоток.
Вообще, когда разрабатываете криптосистему, обращайте внимание на все возможные атаки. Кейс "у атакующего есть только одно перехваченное сообщение и знание алгоритма" - самый простой. Но что если:
Атакующий может перехватить сотни и тысячи сообщений зашифрованных одним ключом? Как я уже говорил, в вашем примере - он просто поксорит эти сообщения между собой и таким образом избавится от вашего шифра
Атакующий может подсунуть вам plaintext, который вы зашифруете? Это не так уж маловероятно, как кажется. Тогда он может подсунуть вам все нули и получить гаммирующую последовательность в чистом виде. Дальше ксорим ее с любым зашифрованным сообщением и вуаля!
Что если атакующий знает минимум одну пару шифротекст/открытый текст? Он может поксорить их между собой и получить гаммирующую последовательность. Дальше см. предыдущий пункт.
Что если атакующий может слать вам для проверки тысячи/миллионы сообщений? Например сервер ожидает запрос зашифрованный определенным ключом и отдает разные коды ошибок в случае если ему удалось расшифровать запрос и увидеть там валидные данные или нет.
Это то что вспомнилось из головы. На самом деле атак больше.
Там собрано кучу упражнений по взлом шифров. Вы научитесь делать это на практике. Ну и соответственно понимать, как проектировать системы чтобы ваш шифр не поломали так легкою
Вы изобрели режим шифрования CTR, только у вас вместе IV/Nonce - Main Key, а вместо блочного шифра - хеш функция.
Проблема тут в том, что нельзя зашифровать два разных сообщения одним ключом. Точнее, зашифровать то можно, но атакующий поксорит их между собой и таким образом получит два поксоренных но незашифрованных сообщения. Это сильно упрощает анализ, особенно если сообщений не два, а хотя бы десяток.
Вам надо добавить случайный IV к каждому сообщению, как делают все режимы шифрования кроме EBC. Тогда фокус с XOR больше не прокатит.
Да нет, это обычное гаммирование. Им все пользуются даже когда юзают AES например. Почитайте про режимы CTR или GCM (если хочется еще и аутентификации). Их можно применять с любым блочным шифром, хоть AES, хоть DES.
Ну двигатель в моем электрогенераторе всего на 500 часов работы рассчитан. Потом ему запчасти менять надо. А масло менять - так еще чаще, каждых 50 часов, кажется.
Переучивать приходится если начали работать с закрытым решением, а потом его у вас отобрали (лицензии больше не продают, государство запретило, производитель прекратил поддержку, мало ли причин).
А если вы сразу начали с OSS решений, то переучивать никого не надо. И отобрать их сильно сложнее.
Я как бы все понимаю... Кого угодно могут взломать и зашифровать. Но не иметь бекапа на такой случай - это вообще как?
... задолго до появления компьютеров. Ваш баланс в банке раньше считали и хранили на бумажке. Окей, деньги можно было не хранить в банке, но резаной бумагой они от этого быть не перестанут. Вся их ценность только в том что другие люди тоже верят в их ценность.
Или вот паспорт. Вы сколько угодно можете доказывать что вы подданный Британской Короны но без паспорта вам не поверят.
Вы можете выглядеть хоть на 90 лет, но если вы не покажете пенсионное свидетельство то вам могут отказать в бесплатном проезде.
Вы можете хоть обхаркать кровью весь отдел кадров, но без больничного у вас будут больше проблемы, если вас неделю не было на работе.
Если у вас есть каперское свидетельство - вы можете безнаказано брать на абордаж корабли. Если нет - ну значит нет, добро пожаловать на виселицу.
Я немного далек от это области, поэтому возможно не совсем понимаю... Зачем хранить сгенерированный код в репозитории? Он же генерируется.
В наших проектах мы тоже используем генерацию кода, я подозреваю что любой более-менее большой проект страдает этим. Но зачем же запихивать то что сгенерировали в гит? Билд система должна (пере-)генерировать эти файлы локально. А то мы так дойдем до того, что еще и объектные файлы в гите держать будем...
Откуда вы знаете? На картинке нарисованы линии. Возможно - эти линии - это проекция трехмерного объекта на двумерную плоскость. А возможно - просто линии.
Почему "моя перспектива"? Это же вы написали про смежника который провалил сроки. Теперь вы пытаетесь сказать что это уже не "смертельно опасно"? Или как понимать ваши слова?
А если сроки провалите вы? Это только в кино к вам с фронта притаскивают доктора всех наук, который все знает и все делает за две недели.
А вот если нет такого человека? А вам поручили... ну например разработать жаропрочный сплав для лопаток в турбине. Вы попробовали 100 разных вариантов, вроде бы нащупали закономерность но надо еще полгода чтобы получить финальный результат. Вот только к вам уже стучатся люди в коже и ведут в машину с надписью ХЛЕБ. Потому что вы провалили сроки, результата нет, Берия недоволен. Как вам такая перспектива?
А вы сами то хотели бы поработать под руководством Берии?
Вот этого я не знаю. Но у них там есть два датума. Один вот этот вот со смещениями, а второй - нормальный. Возможно для работы с кадастром они используют второй датум.
Я ниже писал про ЧПУ станки и мне там же написали что даже полиграфическое оборудование имеет схожие ограничения. Думать что Никона с Кэноном не будет такой же фигни - несколько наивно.
(В конце концов, литограф - это же такой полиграфический станок с очень мелким размером отпечатка /s).
... лет 10 назад
https://news.ycombinator.com/item?id=7015417
Офигеть новость. Некоторые CNC станки блокируются если их просто перенести в соседний цех. А если их перевести в другую страну - они в принципе не будут работать. И все об этом знают.
https://www.reddit.com/r/engineering/comments/1upuap/highend_cnc_machines_have_gyroscopes_and_gps_to/
Нет, все куда проще. Вы же шифруете вот так
ciper=HASH(mainkey + chunkid) XOR plain.Допустим у у нас есть два заширфованных текста:С1 = HASH(mainkey + chunkid) XOR plain1иС2 = HASH(mainkey + chunkid) XOR plain2.Делаем
C1 XOR C2и получаемplain1 XOR plain2потому что часть сHASH()сократится. Анализироватьplain1 XOR plain2уже намного проще, особенно если можно набрать несколько таких пар. Но в любом случае на этом моменте шифр уже сломан.Именно! Но если у вас гамма-последовательность каждый раз разная (благодаря случайным IV), то это уже не проблема.
ну можно и так. Но лучше считать
HASH(mainkey + IV + chunkid), символ + тут - это конкатенация, а не арифметическое сложение, если что.А его надо хранить. При шифровании генерируете 16 случайных байт и кладете их в самое начало файла, например. Или в конец. Их не надо никак шифровать или прятать. Главное требование - вектор должен быть разным каждый раз. И пофиг что его всем видно. При расшифровке, соответственно сначала читаете IV, потом уже основной шифропоток.
Вообще, когда разрабатываете криптосистему, обращайте внимание на все возможные атаки. Кейс "у атакующего есть только одно перехваченное сообщение и знание алгоритма" - самый простой. Но что если:
Атакующий может перехватить сотни и тысячи сообщений зашифрованных одним ключом? Как я уже говорил, в вашем примере - он просто поксорит эти сообщения между собой и таким образом избавится от вашего шифра
Атакующий может подсунуть вам plaintext, который вы зашифруете? Это не так уж маловероятно, как кажется. Тогда он может подсунуть вам все нули и получить гаммирующую последовательность в чистом виде. Дальше ксорим ее с любым зашифрованным сообщением и вуаля!
Что если атакующий знает минимум одну пару шифротекст/открытый текст? Он может поксорить их между собой и получить гаммирующую последовательность. Дальше см. предыдущий пункт.
Что если атакующий может слать вам для проверки тысячи/миллионы сообщений? Например сервер ожидает запрос зашифрованный определенным ключом и отдает разные коды ошибок в случае если ему удалось расшифровать запрос и увидеть там валидные данные или нет.
Это то что вспомнилось из головы. На самом деле атак больше.
Если вам реально интересна криптография - сходите на https://cryptopals.com/
Там собрано кучу упражнений по взлом шифров. Вы научитесь делать это на практике. Ну и соответственно понимать, как проектировать системы чтобы ваш шифр не поломали так легкою
Вы изобрели режим шифрования CTR, только у вас вместе IV/Nonce - Main Key, а вместо блочного шифра - хеш функция.
Проблема тут в том, что нельзя зашифровать два разных сообщения одним ключом. Точнее, зашифровать то можно, но атакующий поксорит их между собой и таким образом получит два поксоренных но незашифрованных сообщения. Это сильно упрощает анализ, особенно если сообщений не два, а хотя бы десяток.
Вам надо добавить случайный IV к каждому сообщению, как делают все режимы шифрования кроме EBC. Тогда фокус с XOR больше не прокатит.
Да нет, это обычное гаммирование. Им все пользуются даже когда юзают AES например. Почитайте про режимы CTR или GCM (если хочется еще и аутентификации). Их можно применять с любым блочным шифром, хоть AES, хоть DES.
А у автора? :)
Ну двигатель в моем электрогенераторе всего на 500 часов работы рассчитан. Потом ему запчасти менять надо. А масло менять - так еще чаще, каждых 50 часов, кажется.
Скоростью относительно чего?
Функция смещения непрерывная. Поэтому ничто никуда не скачет. Просто сжимается-растягивается.