Позвоните в саппорт крупной фирмы. Вам скорее всего ответит голос с индийским акцентом. Если вы его понимаете, то считайте, что вы более-менее воспринимаете английскую речь на слух.
Чёрный английский это ещё ерунда по сравнению с индийским и китайским английским. У первых произношение с каким-то пробулькиванием, а вторые половину букв не выговаривают.
Мне одна знакомая как-то рассказывала про более неприятный конфуз со словом wet, когда она хотела сказать, что вспотела. Об этом в словарях не пишут, но тут это слово могут понять не так, как вы думаете, особенно если вы женского пола. Хотя, если вы качаете из интернета много нехороших фильмов, то вы скорее всего знаете, как его тут понимают.
Это так кажется. Произношение другое. Да, тут без проблем поймут British English, хотя и считают это произношение смешным (типа как украинский звузит для русского). Но бывают такие слова, которые произносятся очень по-другому. Лично меня как-то по приезду поставило в тупик слово schedule. Я не понимал, что это за слово такое — «скедл» (даже ближе к скидл), даже в лингво транскрипция не такая. А американцы напрочь не понимали мой «шедул».
И ещё попробуйте попросить hot tea в каком-нибудь кафе, вас скорее всего переспросят, потому что тут «o» обычно произносятся как «а». Ну и общеизвестное произношение r когда у британцев его обычно не произносят, хотя это тут обычно поймут.
Ну, собственно, я лично именно для таких нужд чаще всего и использую эти свои алгоритмы. Именно так — бывает нужно связывать delphi/FPC, Java, JavaScript, Perl. В случае Delphi/FPC у меня имплементации на ассемблерах x86 и x64, а в оригинале (20 лет назад в дипломе девочки) это был Ассемблер IBM 370.
Я уже в комментах писал про это. Конечно да, основная сложность во взломе первой идеи — это добыть сам алгоритм, и это явно больше чем полдела. Но, допустим, ключи (в данном случае параметры генератора) не присутствуют в коде — это я оставил на усмотрение программиста. Математическая задача нахождения этих параметров довольно нетривиальна и она сильно зависит от функций. Если приоритетом была скорость, то битность параметров скорее всего определяется битностью платформы, но я специально не оговаривал то, что делается в F() и Q(), а там этих параметров может быть сколько угодно. Подбирать брутфорсом можно, тем более к счастью-несчастью алгоритм быстрый, но какой будет критерий подбора, если в начале идёт мусор? Да, доказать криптостойкость даже для какой-то конкретной реализации будет проблематично, а оно вам действительно важно для этих применений? Вон радиообмен военных лётчиков НАТО слушают и картинку с предаторов без проблем смотрят, а вы говорите… Кстати, для предаторов этого шифра было бы достаточно — доступ к его коду получить непросто, для этого сначала нужно его сбить или выкрасть.
О преимуществах UDP никто и не заикался… А также и том, что конкретная реализация с использование этих идей будет именно поточная. Обратите внимание, что описанная вами проблема касается в основном передачи потоков через непотоко-ориентированные каналы, т.е. это скорее затронет поточные шифры, да и то зависит от того, как их использовать. Если сделать шифрование блока/сообщения самодостаточным, то такой проблемы нет.
Когда-то какие-то пессимисты тоже ругали эти алгоритмы. А может какая-то из идей приглянётся очередному камазу мозгов и будет использована в неком новом алгоритме? Как знать…
Придумывать уже не надо — я же не зря надрывался, когда статью писал. Так что этот пункт уже отпадает. (это я нашутил)
В конце концов все эти поточные шифры кто-то когда-то изобрёл, и сделали это люди (скорее всего) как мы. Развелось их (шифров) уже столько, что время, потраченное на выбор алгоритма, уже сопоставимо со временем написания своего. Да, я осознаю, что защита слабаная на коленке и основанная на закрытости кода скорее всего устоит лишь до первой действительно серьёзной попытки взлома. Но тут такой задачи и не ставилось, да и не уверен я, что он так просто сдастся… Хотя у меня и есть некие идеи по взлому этого кода, но математически эта задача непростая, а идеи изложенные тут очень generic, так что при необходимости его можно легко отмасштабировать для увеличения стойкости, например, увеличить битность параметров генератора ключей.
Я всё равно настаиваю, что использовать SSL может быть не проще в каких-то ситуациях. Случаи бывают разные. Допустим, у вас микропроцессор с ограниченным объёмом ROM и RAM, и openssl там нет. Обычно в таких случаях полагаются либо на hardware решения на регистрах сдвига, но если нужно именно простое программное решение? Я соглашусь, что при наличии соответствующих библиотек может быть проще написать и отладить с openssl (или каком-то другом алгоритме), но будет ли это быстрее работать? Не верю, за исключением, может быть случаев, когда имеется hardware поддержка.
Проще чего? Куда уж проще-то? Сложность "любого понравившегося поточного алгоритма" вы учитываете в общей сложности своего алгоритма?
Кстати, применение поточного алгоритма в лоб с одим ключом к одинаковым данным даёт одинаковый результат, что уже само по себе недостаток с точки зрения криптографии. В статье указано, как с этим просто забороться. Хотя идея добавления мусора перед данными не нова, но в своё время я этот велосипед изобрёл сам (интернета тогда, можно сказать, не было).
Собственно, в статье даются идеи, изложенные на пальцах. Уверен, что кому-то эти идеи будут полезны.
Во-первых, тут не излагается конкретный алгоритм, а даются оригинальные идеи (по-крайней мере две).
Во-вторых, эти идея не обязательно использовать для потоков, более того, идея шафлера вообще может быть использована для чего-то далёкого от шифрования.
В-третьих, сравнивать скорости имеет смысл только для конкретных реализаций в конкретных условиях. Хотя у меня есть большие сомнения, что можно обогнать такую простую арифметику, как здесь.
В-четвёртых, сравнивать криптостойкость… А это сильно важно надо для тех применеий для которых оно рассчитано? Она очевидно лучше, чем у часто применяемого XOR с фиксированым ключом и использующих его это почему-то не сильно волнует, причем этот алгоритм ненамного сложнее в реализации.
Иногда применить SSL не проще. SSL предполагает наличие сокета, точнее, он сам является сокетом. И он уж явно более затратный по ресурсам. Даже если забыть о том, что эти простенькие алгоритмы можно использовать вообще для чего-то несетевого, то всё равно даже и для сети можно найти применения, например, подумайте о том, как сделать нечто такое для UDP.
Бостон?
И ещё попробуйте попросить hot tea в каком-нибудь кафе, вас скорее всего переспросят, потому что тут «o» обычно произносятся как «а». Ну и общеизвестное произношение r когда у британцев его обычно не произносят, хотя это тут обычно поймут.
В конце концов все эти поточные шифры кто-то когда-то изобрёл, и сделали это люди (скорее всего) как мы. Развелось их (шифров) уже столько, что время, потраченное на выбор алгоритма, уже сопоставимо со временем написания своего. Да, я осознаю, что защита слабаная на коленке и основанная на закрытости кода скорее всего устоит лишь до первой действительно серьёзной попытки взлома. Но тут такой задачи и не ставилось, да и не уверен я, что он так просто сдастся… Хотя у меня и есть некие идеи по взлому этого кода, но математически эта задача непростая, а идеи изложенные тут очень generic, так что при необходимости его можно легко отмасштабировать для увеличения стойкости, например, увеличить битность параметров генератора ключей.
Кстати, применение поточного алгоритма в лоб с одим ключом к одинаковым данным даёт одинаковый результат, что уже само по себе недостаток с точки зрения криптографии. В статье указано, как с этим просто забороться. Хотя идея добавления мусора перед данными не нова, но в своё время я этот велосипед изобрёл сам (интернета тогда, можно сказать, не было).
Собственно, в статье даются идеи, изложенные на пальцах. Уверен, что кому-то эти идеи будут полезны.
Во-вторых, эти идея не обязательно использовать для потоков, более того, идея шафлера вообще может быть использована для чего-то далёкого от шифрования.
В-третьих, сравнивать скорости имеет смысл только для конкретных реализаций в конкретных условиях. Хотя у меня есть большие сомнения, что можно обогнать такую простую арифметику, как здесь.
В-четвёртых, сравнивать криптостойкость… А это сильно важно надо для тех применеий для которых оно рассчитано? Она очевидно лучше, чем у часто применяемого XOR с фиксированым ключом и использующих его это почему-то не сильно волнует, причем этот алгоритм ненамного сложнее в реализации.