Подскажите легкий для CPU и надежный аглогитм криптографии.
Насколько я понимаю легкий может быть только симметричный алгоритм.
Желательно поточный алгоритм, т.к. я думаю он более надежен чем блочный.
Здравствуйте, edx67, Вы писали:
E>Подскажите легкий для CPU и надежный аглогитм криптографии. E>Насколько я понимаю легкий может быть только симметричный алгоритм. E>Желательно поточный алгоритм, т.к. я думаю он более надежен чем блочный.
Самый простой и легкий — когда длина ключа равна длине сообщения
Здравствуйте, edx67, Вы писали:
E>Подскажите легкий для CPU и надежный аглогитм криптографии. E>Насколько я понимаю легкий может быть только симметричный алгоритм. E>Желательно поточный алгоритм, т.к. я думаю он более надежен чем блочный.
Алгоритм для криптографии... Все равно, что подсказать машину, что бы ездить. Но я попробую. Я так понял, тебя интересует шифрование. Оно есть двух видов: симметричное и асимметричное. Симметричное работает на порядок быстрее асимметричного ввиду алгоритмической сложности последнего (очень тяжелые вычисления над полями).
Легкий и быстрый алгоритм шифрования, родной, советский. Простой и надежный как и АК. ГОСТ 28147-89. Есть все модификации: поточный, с обратной связью, выработка иммитовставок (что-то на подобие ЭЦП). Есть готовые реализации. Пользуйся на здоровье.
Здравствуйте, Turyst, Вы писали:
T>Здравствуйте, edx67, Вы писали:
E>>Подскажите легкий для CPU и надежный аглогитм криптографии. E>>Насколько я понимаю легкий может быть только симметричный алгоритм. E>>Желательно поточный алгоритм, т.к. я думаю он более надежен чем блочный.
T>Самый простой и легкий — когда длина ключа равна длине сообщения
Совершенная криптосистема по Шеннону. Только и у нее есть слабое место, генератор случайного ключа. Т.к. абсолютную случайность... ну ученые до сих пор спорят, существует ли она. Плюс проблема передачи ключа получатели шифртекста.
A>Алгоритм для криптографии... Все равно, что подсказать машину, что бы ездить. Но я попробую. Я так понял, тебя интересует шифрование. Оно есть двух видов: симметричное и асимметричное. Симметричное работает на порядок быстрее асимметричного ввиду алгоритмической сложности последнего (очень тяжелые вычисления над полями).
A>Легкий и быстрый алгоритм шифрования, родной, советский. Простой и надежный как и АК. ГОСТ 28147-89. Есть все модификации: поточный, с обратной связью, выработка иммитовставок (что-то на подобие ЭЦП). Есть готовые реализации. Пользуйся на здоровье.
Здравствуйте, edx67, Вы писали:
E>Подскажите легкий для CPU и надежный аглогитм криптографии.
опиши задачу, что шифровать, для чего, кто и когда будет расшифровывать, объемы данных и т.п.
E>Насколько я понимаю легкий может быть только симметричный алгоритм. E>Желательно поточный алгоритм, т.к. я думаю он более надежен чем блочный.
E>>Подскажите легкий для CPU и надежный аглогитм криптографии.
_>опиши задачу, что шифровать, для чего, кто и когда будет расшифровывать, объемы данных и т.п.
E>>Насколько я понимаю легкий может быть только симметричный алгоритм. E>>Желательно поточный алгоритм, т.к. я думаю он более надежен чем блочный.
_>это вторичные вопросы
Передача файлов например, причем в локальной сети скорость может быть до 100 Мбит/с
Блочный не хочеться использовать, т.к. придеться выравнивать до границы блока — что не хочеться.
И потом блочный вроде как легче взломать.
Здравствуйте, edx67, Вы писали:
A>>Алгоритм для криптографии... Все равно, что подсказать машину, что бы ездить. Но я попробую. Я так понял, тебя интересует шифрование. Оно есть двух видов: симметричное и асимметричное. Симметричное работает на порядок быстрее асимметричного ввиду алгоритмической сложности последнего (очень тяжелые вычисления над полями).
A>>Легкий и быстрый алгоритм шифрования, родной, советский. Простой и надежный как и АК. ГОСТ 28147-89. Есть все модификации: поточный, с обратной связью, выработка иммитовставок (что-то на подобие ЭЦП). Есть готовые реализации. Пользуйся на здоровье.
E>А что вы думаете по поводу RC4 или SEAL ?
Википедия вам про него все расскажет. Но в целом он признан устаревшим.
SEAL — никогда не использовал. Возможно у вас будут проблемы с получением его реализации. Т.к. он защищен патентами.
Но для чего вам шифрование надо? Отсюда будут и рекомендации.
Здравствуйте, edx67, Вы писали:
E>Передача файлов например, причем в локальной сети скорость может быть до 100 Мбит/с
Ну, в плане простоты реализации и скорости работы мне больше всех нравится RC6
E>Блочный не хочеться использовать, т.к. придеться выравнивать до границы блока — что не хочеться.
Тебе все равно придется использовать какой либо из режимов (http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation)
Например тот же CFB позволяет использовать блочный шифр как потоковый.
E>И потом блочный вроде как легче взломать.
В срочном порядке ознакамливайся с теорией.
Здравствуйте, edx67, Вы писали:
E>>>Подскажите легкий для CPU и надежный аглогитм криптографии.
_>>опиши задачу, что шифровать, для чего, кто и когда будет расшифровывать, объемы данных и т.п.
E>>>Насколько я понимаю легкий может быть только симметричный алгоритм. E>>>Желательно поточный алгоритм, т.к. я думаю он более надежен чем блочный.
_>>это вторичные вопросы
E>Передача файлов например, причем в локальной сети скорость может быть до 100 Мбит/с E>Блочный не хочеться использовать, т.к. придеться выравнивать до границы блока — что не хочеться. E>И потом блочный вроде как легче взломать.
На самом деле, блочным вам тут очень даже подходит. Ведь данные по сети передаются пакетами.
У обычного блочного алгоритма есть один минус, одинаковые блоки представляются одинаковыми шифртекстами. Но это решается сцеплением блоков. Но это также и его плюс. При выпадении одного блока, все остальные все равно можно будет расшифровать.
Что могу порекомендовать в целом. Не использовать старые иностранные алгоритмы. Т.к. они в больше части были разработаны с учетом аппаратной реализации. И на процессорах они работают медленно. В отличие от советского алгоритма. Который был разработан как будто специально под 32-х битные процессоры.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, edx67, Вы писали:
E>>Блочный не хочеться использовать, т.к. придеться выравнивать до границы блока — что не хочеться. CC>Тебе все равно придется использовать какой либо из режимов (http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation) CC>Например тот же CFB позволяет использовать блочный шифр как потоковый.
Не обязательно. Есть поточные "от природы" алгоритмы. Тот же RC4. Если описать принцип их работы в двух словах, они генерируют ключ равный длине сообщения, а дальше ксорят с сообщением. Вся соль алгоритма в генерации бесконечного ключа, из секретного ключа.
E>>И потом блочный вроде как легче взломать. CC>В срочном порядке ознакамливайся с теорией.
E>>Передача файлов например, причем в локальной сети скорость может быть до 100 Мбит/с E>>Блочный не хочеться использовать, т.к. придеться выравнивать до границы блока — что не хочеться. E>>И потом блочный вроде как легче взломать.
A>На самом деле, блочным вам тут очень даже подходит. Ведь данные по сети передаются пакетами.
A>У обычного блочного алгоритма есть один минус, одинаковые блоки представляются одинаковыми шифртекстами. Но это решается сцеплением блоков. Но это также и его плюс. При выпадении одного блока, все остальные все равно можно будет расшифровать.
Выпадений не будет, т.к. используется TCP
A>Что могу порекомендовать в целом. Не использовать старые иностранные алгоритмы. Т.к. они в больше части были разработаны с учетом аппаратной реализации. И на процессорах они работают медленно. В отличие от советского алгоритма. Который был разработан как будто специально под 32-х битные процессоры.
Здравствуйте, edx67, Вы писали:
E>Подскажите легкий для CPU и надежный аглогитм криптографии. E>Насколько я понимаю легкий может быть только симметричный алгоритм. E>Желательно поточный алгоритм, т.к. я думаю он более надежен чем блочный.
Если кто-то готов предоставить мне готовое решение на с++ за разумные деньги, я могу заплатить.
Здравствуйте, edx67, Вы писали:
E>Здравствуйте, edx67, Вы писали:
E>>Подскажите легкий для CPU и надежный аглогитм криптографии. E>>Насколько я понимаю легкий может быть только симметричный алгоритм. E>>Желательно поточный алгоритм, т.к. я думаю он более надежен чем блочный.
E>Если кто-то готов предоставить мне готовое решение на с++ за разумные деньги, я могу заплатить.
Реализаций ГОСТа полно на просторах сети. Даже с ассемблерными вставками. Для иностранных алгоритмов можно использовать OpenSSL или CryptoAPI, если по Windows. А главное, все абсолютно бесплатно. Правда придется разбираться с документацией.
Здравствуйте, Acteon, Вы писали:
A>Не обязательно. Есть поточные "от природы" алгоритмы. Тот же RC4. Если описать принцип их работы в двух словах, они генерируют ключ равный длине сообщения, а дальше ксорят с сообщением. Вся соль алгоритма в генерации бесконечного ключа, из секретного ключа.
Камрад, мне не надо рассказывать как работает RC4, я в теме.
Я вообще то говорил о том, что даже при использовании блочных шифров можно обойтись без выравнивания до границы блока.
CC>>В срочном порядке ознакамливайся с теорией. A>Это никогда не помешает.
Я б даже сказал что базовые знания обязательны для того, чтоб правильно использовать готовые алгоритмы, не наделав при этом ошибок, которые могут свести на нет все потуги по прикручиванию шифрования.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Acteon, Вы писали:
A>>Не обязательно. Есть поточные "от природы" алгоритмы. Тот же RC4. Если описать принцип их работы в двух словах, они генерируют ключ равный длине сообщения, а дальше ксорят с сообщением. Вся соль алгоритма в генерации бесконечного ключа, из секретного ключа.
CC>Камрад, мне не надо рассказывать как работает RC4, я в теме. CC>Я вообще то говорил о том, что даже при использовании блочных шифров можно обойтись без выравнивания до границы блока.
Ну значит edx67 почитает, и проникнется духом поточных шифров.
CC>>>В срочном порядке ознакамливайся с теорией. A>>Это никогда не помешает. CC>Я б даже сказал что базовые знания обязательны для того, чтоб правильно использовать готовые алгоритмы, не наделав при этом ошибок, которые могут свести на нет все потуги по прикручиванию шифрования.
К сожалению, в большинстве случаев, даже этих обязательных базовых знаний нет. Сколько раз мне говорили: "Мы хотим защитить вот это файл, зашифруй нам его". При этом даже понятия не имели, а где же будет потом храниться ключ шифрования (зашит в коде). Вот где защита.
Здравствуйте, Acteon, Вы писали:
A>Что могу порекомендовать в целом. Не использовать старые иностранные алгоритмы.
Не согласен со словом "иностранные". Чем они объективно хуже?
A>Т.к. они в больше части были разработаны с учетом аппаратной реализации. И на процессорах они работают медленно.
Это не так. К примеру кандидаты на AES разрабатывались с учётом эффективности как аппаратной так и программной реализации.
A> В отличие от советского алгоритма. Который был разработан как будто специально под 32-х битные процессоры.
Он построен на сети Фейстеля. Которая кстати используется в куче других шифров.
Впрочем это всё измеряется.
По твоему выходит что к примеру иностранные Twofish и RC6 есть гуано а построенный на тех же принципах старый ГОСТ есть конфетка?
Здравствуйте, edx67, Вы писали:
E>Если кто-то готов предоставить мне готовое решение на с++ за разумные деньги, я могу заплатить.
С тебя пиво: http://rsdn.ru/forum/alg/2758606.aspx
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Acteon, Вы писали:
A>>Что могу порекомендовать в целом. Не использовать старые иностранные алгоритмы. CC>Не согласен со словом "иностранные". Чем они объективно хуже?
A>>Т.к. они в больше части были разработаны с учетом аппаратной реализации. И на процессорах они работают медленно. CC>Это не так. К примеру кандидаты на AES разрабатывались с учётом эффективности как аппаратной так и программной реализации.
Я имел ввиду реально старые, такие как DES. А что, используют же до сих пор хеш MD5 который уже не выдерживает никакой критики.
A>> В отличие от советского алгоритма. Который был разработан как будто специально под 32-х битные процессоры. CC>Он построен на сети Фейстеля. Которая кстати используется в куче других шифров. CC>Впрочем это всё измеряется.
CC>По твоему выходит что к примеру иностранные Twofish и RC6 есть гуано а построенный на тех же принципах старый ГОСТ есть конфетка?
Нет. Вообще все зависит от целей. Для себя можно использовать все что хочешь. Тут придется верить криптографам, что это алгоритм хорош, а это не очень. Вся криптография держится на вере. Сказать, что этот алгоритм объективно лучше другого, можно только об объективных параметрах. Скорость работы, требуемая память, и т.п. Надежность — объективным параметром не является.
Вообще, со своего опыта могу сказать, что хватит даже элементарных алгоритмов. Т.к. не это сейчас узкое место, а человек. Управление ключами — вот реальная головная боль.
Здравствуйте, Acteon, Вы писали:
A>Нет. Вообще все зависит от целей. Для себя можно использовать все что хочешь. Тут придется верить криптографам, что это алгоритм хорош, а это не очень. Вся криптография держится на вере.
Вай!
А как же криптоанализ?
A> Сказать, что этот алгоритм объективно лучше другого, можно только об объективных параметрах. A> Скорость работы, требуемая память, и т.п. Надежность — объективным параметром не является.
Просто нет слов.
Может я неправильно тебя понял, но ты вот тут утверждаешь что надёжность шифра объективно оценить нельзя, так?
ГОСТ 28147-89. Есть все модификации: поточный, с обратной связью, выработка иммитовставок (что-то на подобие ЭЦП). Есть готовые реализации. Пользуйся на здоровье.
