|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Возвращаюсь периодически к теме UDP-передачи. Кто не в курсе - неважно, это просто подзадача, условия ниже. Задача: зашифровать пакет на отправителе, на получателе расшифровать и убедиться что верно расшифровано. Сначала была классическая мысль посчитать хэш нешифрованных данных и добавить к данным, по получении после расшифровки снова посчитать и сравнить. Потом появилась мысль как-то совместить шифрование и подсчет хэша. Зачем четыре прохода делать вместо двух? Шифрование CBC , т.е. данные влияют на то что в итоге получится. Ключ шифрования не обсуждаем, он передан безопасным способом. В итоге пришел к выводу что достаточно в конец дописать пару байт константы (0x5AA5) и после дешифрования проверить. Вроде все отлично, но есть сомнения: не создал ли я дыру, через которую все расшифруют? Исходники Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65.
Результат Код: plaintext 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2019, 20:02 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
В твоём протоколе все UDP пакеты независимые? Или образуют Stream? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2019, 20:13 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
maytonВ твоём протоколе все UDP пакеты независимые? Или образуют Stream? Образуют Stream, в котором контролируется правильность полученного, это вложенный уровень, его не обсуждаем. В данном случае надо просто понять что пакет был зашифрован тем же симметричным ключом, которым расшифрован, при этом не ослабить шифрование. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2019, 20:18 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
В каждый конец открытого текста пакета дописываются 0x5AA5 ? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2019, 20:30 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
maytonВ каждый конец открытого текста пакета дописываются 0x5AA5 ? Да. Результат выполнения кода Код: plaintext 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2019, 20:31 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Результат это то во что трансформировалось 0x5AA5 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2019, 20:34 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Юзай спокойно. При правильном использовании CBC тебе ничего не угрожает. В интрернетах ходит миллиард пакетов с стандартной шапкой <html И ничо. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2019, 20:36 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Что-то мне кажется, что зная что последние байты всегда константа, должно быть очень легко востановить часть пароля (2 байта пароля) При разных длинах пакетов, будем востанавливать разные части пароля. Т.ч. накопив передачи с разной длиной пакетов, в какой-то момент можно будет реконструировать пароль Хотя, возможно, мне это только кажется, C++ под руокй нет. т.ч. код не запустить и зашифрованные пакет не посмотреть. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2019, 20:40 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Dima TРезультат это то во что трансформировалось 0x5AA5 кроме того, во что трансфорировалось 0x5AA5 нужно еще и предыдущий байт(ы) видеть. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2019, 20:42 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
maytonЮзай спокойно. При правильном использовании CBC тебе ничего не угрожает. В интрернетах ходит миллиард пакетов с стандартной шапкой <html И ничо. У меня должен быть полный хаос в том что уходит в сеть, чтобы не было этого PS на дату глянул, пять лет уже пишу, юбилей )))) ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2019, 20:44 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Leonid Kudryavtsevлегко востановить часть пароля (2 байта пароля) Чтобы узнать 2 байта пароля надо знать исходные (шифруемые) данные. Я двумя байтами (вместо 4-х) ограничился из-за трафика, но как понимаю 2 байта приписки имеют выше криптостойкость по сравнению с 4-мя. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2019, 21:10 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Dima TВ итоге пришел к выводу что достаточно в конец дописать пару байт константы (0x5AA5) и после дешифрования проверить. Вроде все отлично, но есть сомнения: не создал ли я дыру, через которую все расшифруют? А шифрование то реально такое, как в приведенном исходнике? Я бы скорее не за пару байт в конце беспокоился. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2019, 21:35 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Не знаю как Дима распространяет ключи. Вручную. ? На флешке? Но я бы позаботился о периодическом их обновлении. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2019, 22:06 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
BarloneDima TВ итоге пришел к выводу что достаточно в конец дописать пару байт константы (0x5AA5) и после дешифрования проверить. Вроде все отлично, но есть сомнения: не создал ли я дыру, через которую все расшифруют? А шифрование то реально такое, как в приведенном исходнике? Я бы скорее не за пару байт в конце беспокоился. Шифрование реально такое, но ключ разовый на сессию, т.е. отправитель в начале отправки файла/сообщения генерит ключ и передает его в первом пакете. Собственно проблема из-за того что ключей много, и т.к. используется UDP, то может прилететь кусок предыдущей сессии и надо его распознать и проигнорировать. Первый пакет содержит ключ сессии, он шифруется мастер-ключом (он постоянный), вот тут надо подумать чтобы по сессионному невозможно было мастер-ключ восстановить. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2019, 08:11 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Тут старик Керхгофс бы неодобрительно нахмурил брови. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2019, 10:46 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Dima T, ну хотя бы RC4 реализовали. Несмотря на известные слабые места, он гораздо лучше, чем такое. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2019, 11:40 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Dima TВ итоге пришел к выводу что достаточно в конец дописать пару байт константы (0x5AA5) и после дешифрования проверить. Вроде все отлично, но есть сомнения: не создал ли я дыру, через которую все расшифруют? Если сообщение xor-ить случайной (псевдо) последовательностью, то ни разу не страшно. Главное последовательность не повторять, или повторять как-то очень редко, со сдвигами и т.д. Если шифрование двуступенчатое (сначала асимметричное, потом симметричное), тогда первый этап, наверное, лучше без двух байт. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2019, 12:39 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Не надо ничего xor-ить. Xor на фоне шифрования - это бесполезная трата ваших ресурсов. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2019, 14:41 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Алгоритм: Передаём в начале сообщения пару случайных байт и затем в конце сообщения ту же пару. Получатель сверяет и удостоверяется в дешифровании. Можно после первой пары байт давать смещение второй пары, что-б никто не догадался (с). ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2019, 17:34 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
BarloneDima T, ну хотя бы RC4 реализовали. Несмотря на известные слабые места, он гораздо лучше, чем такое. RC4 это потоковое шифрование, а у меня не поток, а фрагменты потока (UDP пакеты), которые будут частично теряться по дороге и надо будет их высылать повторно, следовательно придется их хранить до подтверждения доставки. Но это не самое страшное, пакет может не дойти никогда из-за рубки пакетов по сигнатуре 15824799 . Если я буду шифровать отдельно каждый пакет, то добавив в начало один случайный байт я эту проблему решаю. По этой причине выбран CBC, чтобы сменой первого байта изменить весь пакет до неузнаваемости. С помощью RC4 можно растянуть ключ до размера пакета, станет немного получше. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2019, 17:54 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
alex55555Алгоритм: Передаём в начале сообщения пару случайных байт и затем в конце сообщения ту же пару. Получатель сверяет и удостоверяется в дешифровании. Можно после первой пары байт давать смещение второй пары, что-б никто не догадался (с). Отличная идея. У меня первый байт и так случайный, можно его дважды в конце повторить. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2019, 17:57 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Dima TОтличная идея. У меня первый байт и так случайный, можно его дважды в конце повторить. Посмотрел что получится, получилось не очень: Предпоследний байт всегда одинаковый после шифрования, потестил на разных строках. Какая-то особенность алгоритма. Добавил искажение предпоследнего байта. В итоге вот что получается: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34.
Первый байт случайный, перебрал все варианты кратные 8-ми, он не шифруется, показан как есть, два последних производные от него. Исходник Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2019, 19:08 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Dima TПервый байт случайный, перебрал все варианты кратные 8-ми, он не шифруется Ну тогда может его не первым слать? А первым - просто случайный байт, ни от чего не зависящий и ни на что не влияющий, и пусть его все читают. Так же и про последний, если и он влияет. Опять же про случайное смещение второго не забываем - тоже вариант. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.03.2019, 12:55 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Похоже на number used once. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.03.2019, 17:18 |
|
Пятничная криптостойкость
|
|||
---|---|---|---|
#18+
Размышлял про RC4. Хотелось бы задействовать, но резко усложняется решение в целом, т.к. невозможно зашифровать произвольное место потока. Пришел к выводу что даже если кто-то подслушивающий расшифрует несколько сессионных ключей - это не критично. Это будет достаточно сложно если с помощью RC4 нарастить ключ до размера пакета. Главная проблема в том чтобы не засветить мастер-ключ (МК), который шифрует сессионные. Он постоянный и его расшифровка сводит все шифрование к нулю. Как вариант рассматриваю добавление соли: посчитать MD5(МК+соль) и полученный хэш использовать для шифрования сессионного ключа. Соответственно передавать соль + шифрованный сессионный. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.03.2019, 17:47 |
|
|
start [/forum/topic.php?fid=16&fpage=10&tid=1339965]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
41ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
others: | 47ms |
total: | 197ms |
0 / 0 |