LINUX.ORG.RU

Какой протокол шифрования вы считаете самым безопасным?

 , ,


1

1

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

Был бы очень рад почитать ваши размышления о разных протоколах защиты вообще: от wpa и шифрования в gsm до китайских разработок а-ля v2ray или же вообще tor i2p и т. д. (по крайней мере https, wpa2 и даже хваленный tor, насколько мне известно из статей по безопасности, при желании взламывается).

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

Второй вопрос, наверно более простой… в общем, был у меня как-то роутер от Ростелеком, работал себе работал и тут внезапно стал виснуть намертво, подхожу к нему - все лампочки горят - подключение к провайдеру есть, но он недоступен по интефейсу интернета нет, только хард-резет помогал. Что это было? Старый проц, который просто не вывозил нагрузку или же атаки какие-нибудь? Сейчас у меня естественно другой роутер, с OpenWrt.



Последнее исправление: Reptile (всего исправлений: 1)

Ответ на: комментарий от vvn_black

Что ж… попробуем проще.

Расшифруйте, чтобы было понятно, что вы имеете в виду под, даже можно с примерами и картинками для непонятливых

Для чего? Как минимум, в Википедии есть оные определения в контексте передачи данных по сети. Единственное, что вам не зашло в плане понимания - «протокол шифрования», формально под этим словосочетанием понимается криптографический протокол, я об этом уже писал выше.

В этой теме подразумевается широкий контекст вопроса: «Какой протокол шифрования вы считаете самым безопасным?», то есть говоря так, я имел в виду не только отдельно взятый криптографический алгоритм, но и любые реализации по защите данных в сетях tcp\ip, в которых могут использоваться эти алгоритмы. Под реализацией понимается готовый софт \ железо для конечного пользователя\ей.

Под «безопасностью» я понимаю нецелесообразность расшифровки трафика из вне со стороны атакующего (кем бы он не был: от школьника до спецслужб).

Не получилось проще, не обессудьте)

Reptile
() автор топика
Ответ на: комментарий от Aceler

Потому что это небанальный вопрос. Если субьект X передаёт субьекту Y информацию Z, то вопрос о том, какой протокол чего-либо наиболее безопасен не имеет смысла без ответов на вопросы, кто такие XYZ, и какая цель у каждого.

Здесь должна быть известная шутка про «хорошую попытку».

X и Y - пользователь 1 и пользователь 2 (или сервер\а), а Z - данные.

Во всех случая будут совершенно разные модели угроз и протоколы, безопасные с точки зрения одной модели могут быть вообще неприемлемы с другой.

Это понятно. Вероятно, если речь идет о «самой безопасной передаче данных», то уровень безопасности должен быть таким, при котором данные не должны быть прочитаны или модифицированы из вне посторонними, как минимум, а как максимум - чтоб даже сам факт передачи значащих данных было сложно установить из вне: Проще говоря, либо переменная Z должна быть обезличена, либо все переменные сразу.

Или, если все же уйти от сложных формулировок и привести банальный пример, то: некто X (в Китае) передает Y котиков через HTTPS. Подставьте вместо котиков текст: «Цзиньпинь словно винни пух…» и представьте последствия для передающих)) Можно подставить что угодно: текст, картинки, видео, координаты, коды, суть не изменится - https мало пригоден к передаче чувствительных данных, не говоря уж о закладках и прочем.

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

Reptile
() автор топика
Ответ на: комментарий от Reptile

Судя по тому, как вы широко подходите к вопросу, обобщая свои представления на всех и широко рассуждая в довольно узкой теме, вы не должны были забыть героев классической русской литературы Обломова и Манилова. Они вот тоже любили рассуждать.

Толку только от этого нет никакого.

vvn_black ★★★★★
()
Ответ на: комментарий от anonymous

Отлично существует и используется без всякого HTTP.

Я в постах говорил о HTTPS.

Не строили. Это средство обхода цензуры.

Хмм… они создавали свою реализацию наобум?) Типа а давайте мы забацаем обход цензуры, пацаны! А если серьезно, вероятно, писали этот код рептилойды не хуже гугловских…

Так или иначе - последствия для создателей несоизмеримы со словосочетанием «обход цензуры». Ну, если за «просто обход цензуры исчезают», то у меня вопросов нет.

Нет, вообще нет, просто ни каким боком. Почитай википедию хотя бы внимательно.

Заинтриговали однако! Без шуток. Впредь предлагаю к каждому утверждению прикреплять аргументацию.

Криптографические протоколы - защита данных > данные обычных пользователей в современных реалиях передаются посредством tcp\ip > DPI создавался для анализа таких данных > эта тема о защите трафика, однако вывод - эти вещи никак между собой не связаны. (Сидит задумчивый кот, на головой у него крутиться кружочек и надпись «Подождите, идет загрузка…»).

Reptile
() автор топика
Ответ на: комментарий от Reptile

X и Y - пользователь 1 и пользователь 2 (или сервер\а), а Z - данные.

Если X и Y среднестатистические пользователи, а Z среднестатистические данные, то им нужен среднестатистический протокол.

Можно подставить что угодно: текст, картинки, видео, координаты, коды, суть не изменится

Изменится полностью. Пока ты этого не поймёшь, дальше идти бесполезно.

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

Ладно, я понял - диалогу кабзда. Я попробую в последний путь)

Утверждение: Я говорил о HTTPS в примере выше. Аргумент - пост выше. Вопрос: Почему суть должна изменится, если и передавая текст о политике, и передавая код сейфа в банке - присутствует угроза?

Reptile
() автор топика
Ответ на: комментарий от Reptile

Я в постах говорил о HTTPS.

HTTPS это тот же самый HTTP. Вам ничего не говорит такое «HTTP over TLS» или «HTTP over SSL» - а это и есть определение HTTPS.

Вы вместо того, чтобы в вики посылать сами открыли бы её. И разберитесь, кто же на ком всё-таки стоит, в протоколах, алгоритмах и т.п.

vvn_black ★★★★★
()
Ответ на: комментарий от Reptile

Вопрос: Почему суть должна изменится, если и передавая текст о политике, и передавая код сейфа в банке - присутствует угроза?

Ответ: потому что а) угрозы разные и б) стоимость информации разная.

Если передавать котиков, то никто не будет тратить сотни долларов на расшифровку, а если передавать ключи от биткоинов стоимостью в пару миллионов баксов, то будет. Если передавать что-то, что надо скрыть от правительства США, неплохо бы не пользоваться сертификатами и/или шифрами, выданными или разработанными подконтрольными США организациями и переходить на GPG или ещё что-то. А если передавать что-то, что надо скрыть от пацанов в соседнем дворе, то вполне достаточно пляшущих человечков.

Поэтому безопасность всегда имеет конкретное приложение, а не абстрактное, и изучать приходится частности.

Aceler ★★★★★
()
Ответ на: комментарий от vvn_black

HTTPS это тот же самый HTTP.

Почему? HTTP передает данные в открытую, а HTTPS - нет. Следовательно - они по-разному передают данные. Короче, дело не в том, кто лучше понимает устройство конкретного протокола, а в том насколько конкретная реализация передачи данных подходит под задачу «передать данные и не огрести».

Эх, ладно… не будет дятлами и закончим сий дискус. Ибо мы не сможем разговаривать пока вы упорно выдергиваете из контекста предложения и отсылаете меня учить матчасть, а я пытаюсь догнать почему вы так и не привели примеров вашей точки зрения о разных реализациях. Честно говоря, я так до конца и не понял, что вы мне пытаетесь доказать… если то, что я не в тему сказал: «протокол шифрования», так, это, я уже выше писал об этом, огласил список технологий с помощью которых так или иначе можно модифицировать трафик с целью его защиты от посторонних глаз.

Я просто хотел, чтоб вы высказали свою точку зрения по поводу разных вариантов передачи данных, вот и всё. А пример с HTTPS выше был упрощен для наглядности, я выдвинул там предположение, что шифрование на уровне приложения мало эффективно и легко анализируется, если это будет надо. Таким образом… бла, бла, бла… в общем, если вы разбираетесь в теме, поднятой в этом топике, буду рад почитать ваши размышления, если нет, ну, сорян, что нагрузил) Бывает меня уносит, а человек по факту клал.

Оставлю развитие темы для будущих гостей.

Reptile
() автор топика
Ответ на: комментарий от Reptile

Маша шифрует файл открытым ключом. Закрытый ключ располовинен между Васей и Петей. Ни Вася, ни Петя не знает всего ключа. Какого именно Петю выбрать Васе, зависит от того, кто может держать паяльник. Последнее зависит от данных, от поведения Васи, от окружающей обстановки. Снова возвращаемся к модели угроз, которую тут многократно упоминали.

Vidrele ★★
()
Последнее исправление: Vidrele (всего исправлений: 1)
Ответ на: комментарий от Reptile

В этой теме подразумевается широкий контекст вопроса: «Какой протокол шифрования вы считаете самым безопасным?»

Помните анекдот: «мне не нужно обогнать медведя, мне просто нужно быть быстрее тебя»?

bugfixer ★★★★
()
Ответ на: комментарий от bugfixer

Поискал, освежил память. Интересно, как меня воспринимают?

  • Метод «мне просто нужно быть быстрее тебя», вероятно, сработает только при наличии ботнета, если мы берем в расчет тот факт, что Изюм Михалыч - спец. атакующий (самая высокая степень угрозы в цифровом пространстве).
  • Метод «бежать быстрее медведя», вероятно, сработает при наличии грамотной реализации «бега».
Reptile
() автор топика
Ответ на: комментарий от Reptile

Метод «мне просто нужно быть быстрее тебя», вероятно, сработает только при наличии ботнета

Это работает практически всегда. Кромке шуток. И не только к cyber миру применимо. Например с угонщиками машин та же ситуация: достаточно создать чуть больше проблем по сравнению с машиной стоящей рядом. А в нашем мире ещё и «honey pod» оставлять можно, и «на живца ловить», что называется.

bugfixer ★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от bugfixer

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

Если говорить проще, в условиях «быстрее тебя» (в контексте передачи данных) сама парадигма мышления выглядит для меня так, что Михалыч - идиот. Из этой парадигмы следует, что пользователь может быть быстрее даже если будет юзать HTTPS-PROXY, а если он заюзает TOR, то станет словно гоночный болид))

Reptile
() автор топика
Ответ на: комментарий от anonymous

Ок, если прям до предела упрощать, то в этой теме я:

  1. Упрощенно описал точку зрения о передачи зашифрованных данных.
  2. Спросил какие протоколы и реализации защиты наиболее безопасны.
  3. Привел пример непригодности HTTPS-уровня для передачи нелеквидных данных и толсто намекал, что TOR в этом плане тоже довольно дырявый.
  4. Некоторые пользователи отправили меня учить «матчасть».

Теперь главное: Мне искренне интересно, что подразумевается под матчастью?) И в чем я ошибаюсь или скорее в чем некорректность моих вопросов и выводов относительно передачи неликвидных данных? Можно с ссылками на статьи, для наглядности.

Reptile
() автор топика
Ответ на: комментарий от Reptile

Если говорить проще, в условиях «быстрее тебя»

Как мне видится - в вопросах передачи информации нужно исходить из времени её актуальности: если через пару секунд (условно) никому не будет интересно что у Вас там происходило - ради чего электричество жечь?

bugfixer ★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от Reptile

в чем я ошибаюсь или скорее в чем некорректность моих вопросов и выводов

В базе:

  • в непонимании, что такое протокол, что такое алгоритм и что такое операция, как они связаны
  • в оперировании непонятными определениями, возникающими из п. 1
  • в непонимании работы конкретных протоколов, например того же HTTPS
  • в непонимании, что безопасность сама по себе отдельно от ситуации не бывает, что не бывает сравнительной степени безопасности, что она либо есть (т.е. удовлетворяет условиям ситуации), либо ее нет

И как следствие - скатывание в настолько общие рассуждения, в которых даже места «протоколу шифрования» не находится, не говоря уже об обсуждении чего-то конкретного.

vvn_black ★★★★★
()
Ответ на: комментарий от Reptile

Упрощенно описал точку зрения о передачи зашифрованных данных.

Мы же тут не дурачки, математики не боимся, не надо упрощать.

Привел пример непригодности HTTPS-уровня для передачи нелеквидных данных и толсто намекал, что TOR в этом плане тоже довольно дырявый

У тебя есть технические аргументы в пользу этих гипотез? Ссылки на исследования?

anonymous
()

Самым безопасным является Шифр Вернама с ключами, сгенерированными с помощью истинной случайности (например, используя квантовые флуктуации). Вне зависимости от того, что я или кто-то другой там «считает».

CrX ★★★
()
Ответ на: комментарий от vvn_black

в непонимании

Можете на конкретных примерах тыкнуть носом в мои ошибки? Или лучше «самую вопиющую» на ваш взгляд.

безопасность сама по себе отдельно от ситуации не бывает

А где я рассматривал её отдельно от ситуации? Вроде как это вы хотели оторвать HTTPS от TLS, а я привел пример передачи конкретных данных через оный составной протокол.

не бывает сравнительной степени безопасности

Хм… А разве уровень сложности расшифровки трафика, например, на уровне приложения (прикладной) и на уровне tcp (сетевой) одинаковы? Каким образом? Исходя из вашего суждения я тоже могу сказать, но я лучше предположу, что вы «не понимаете», так как заворачивание трафика на разных уровнях ведет к совершенно разному уровню безопасности.

Reptile
() автор топика
Последнее исправление: Reptile (всего исправлений: 1)
Ответ на: комментарий от anonymous

У тебя есть технические аргументы в пользу этих гипотез? Ссылки на исследования?

Подмена сертификата или расшифровка TLS налету посредством GFW? Скандалы вокруг TOR по типу поимки всех тех, кто размещает там «крайне плохой контент»? Исследования на английском? Статьи на хабре по разным системам обхода цензуры? И т. д.

Когда-нибудь ленивый я забацаю этот эпический список) Ну, серьезно всё лежит на виду, пока ещё…

Reptile
() автор топика
Ответ на: комментарий от Reptile

Для защиты данных?

И всё таки у Вас каша в голове. Вам очевидно что любое шифрование ломается? Вопрос исключительно времени. И ресурсов. И электричества (да да). И криптостойкость тоже электричества стоит. Вопрос исключительно целесообразности.

bugfixer ★★★★
()
Ответ на: комментарий от Vidrele

Эх, теоретики. Просто ключ делится на две части, которые даются двум хранителям.

Ну значит в терморектальном анализе будут задействованы два паяльника.

Qui-Gon ★★★★★
()
Ответ на: комментарий от Reptile

Подмена сертификата или расшифровка TLS налету посредством GFW?

Ты не можешь просто взять и подменить сертификат на свой, если твоему не доверяет клиент. Если сервер использует pinning, то и этого будет недостаточно. То есть клиенту нужно будет явно подтвердить нарушение цепочки сертификатов.

Скандалы вокруг TOR по типу поимки всех тех, кто размещает там «крайне плохой контент»?

Общие слова. Всяких торгашей веществами деанонили в основном методами фишинга и прочей социальной инженерии. Из реалистичных технических атак есть контроль над очень большим числом входных/выходных узлов плюс немного удачи, но цель должна быть очень крупной, не мелочь как в тех случаях. Но проблем с криптографией в Tor нет.

Исследования на английском?

Что «исследования на английском»? Давай, почитаем.

anonymous
()

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

Кстати манагерам на заметку - потенциального админа спросите как он собирается защищать сеть и если скажет поставлю пароли на 20 символов с проверкой словароных слов и требованиями спец-символов не менее половины и менять каждый месяц - гоните прыщеносца поганой метлой ибо такие *удаки для хакера - находка.

Qui-Gon ★★★★★
()
Ответ на: комментарий от Reptile

Можете на конкретных примерах тыкнуть носом в мои ошибки? Или лучше «самую вопиющую» на ваш взгляд.

Заявление, что TLS не существует отдельно от HTTPS. Достаточное количество приложений, сервисов и протоколов смотрит на вас в этом случае с непониманием.

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

Вроде как это вы хотели оторвать HTTPS от TLS

Я не хотел, оно так на самом деле. HTTPS - это HTTP поверх слоя TLS или SSL, которые, вы не поверите, могут существовать отдельно и испоьзуются и в других протоколох.

А где я рассматривал её отдельно от ситуации?

Везде же. Вас aceler пытался вывести на конкретную бытовую ситуацию, но ничего так и не получилось.

А разве уровень сложности расшифровки трафика

При чем тут сложность расшифровки трафика? Есть ситуация, для примера - защитить переписку в телеграме, для этого один чукча предлагает завернуть трафик телеги в впн через тор. Вот, конкретная ситуация и к ней можно определить конкретные условия, что защитить, как защитить, кто должен прочитать переписку, а кто может и т.д. и т.п. Вы видите здесь сетевую модель? А я вижу здесь, что закрыв дверь на сувальдный замок, оставили открытым окно, через которое всё видно.

Как-то так.

vvn_black ★★★★★
()
Ответ на: комментарий от bugfixer

И всё таки у Вас каша в голове.

Ну… Аргументы к суждению предоставите?)

Вам очевидно что любое шифрование ломается?

Ну это же баян… когда стоит вопрос о защите данных, те, кто эти данные защищает, в последнюю очередь думают о электроэнергии)) Наверно. Иначе это будет очень ржачная комедия, где чувак выбирает между дубиной и ценой за свет.

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

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

Reptile
() автор топика

Hу про «протокол шифрования» тут уже насовали, так что я не буду.

А про безопасность - на 100% безопасно такое шифрование, наличие которого принципиально не может быть обнаружено третьими лицами.

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от vvn_black

Заявление, что TLS не существует отдельно от HTTPS. Достаточное количество приложений, сервисов и протоколов смотрит на вас в этом случае с непониманием.

Наверно, мы свободно трактуем понимания друг-друга… Давайте так, я говорил о:

  1. HTTPS, а он (этот «составной» протокол) связан с TLS.

Соответственно, пример передачи кода от сейфа касался конкретного протокола - HTTPS.

  1. HTTPS без TLS - HTTP.
  2. TLS без HTTPS существует, но не наоборот. Понимаете разницу?

Ну и соскок с темы, где я попросил дать несколько определений, а вы отправили меня в википедию.

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

Везде же. Вас aceler пытался вывести на конкретную бытовую ситуацию, но ничего так и не получилось.

Ну, мне показалось, что ситуация с передачей кода более чем конкретная… X передаёт Y текст (код от сейфа). Эту информацию не должны увидеть спецслужбы. Куда конкретней? Далее определяем систему, по которой будет идти передача. И я, соответственно, от имени обычного рядового пользователя ждал от вас размышления по поставленному примеру.

При чем тут сложность расшифровки трафика?

Не понял. Трафик должен передаваться в открытом виде? Если два пользователя передают друг другу текст, картинки или видосики, то они по определению должны быть зашифрованы или замаскированы (одним словом обезличены), при условии, что данные не дожны быть прочитаны посторонними.

Reptile
() автор топика
Последнее исправление: Reptile (всего исправлений: 2)
Ответ на: комментарий от Reptile

TLS без HTTPS существует, но не наоборот. Понимаете разницу?

Штааа-а-а-а, это пишет человек, который на предыдущей странице заявлял:

Мне даже интересно (без шуток) каким образом, например, TLS существует без HTTPS???

Ну, так, вам для будущих переобуваний в воздухе, HTTPS без TLS существует, потому что есть (был) SSL.

Вы опять написали тонну текста и опять о чём-то то своём.

Не понял

Вооооот. ) Потому что у вас всё очевидно, конкретно и т.п. Но со стороны это не так.

vvn_black ★★★★★
()
Ответ на: комментарий от Reptile

…банальные вещи же. Но почему то не получается, вы упорно говорите, что я «не прав», давая в аргумент «базу», без раскрытия своей точки зрения.

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

Какую точку зрения вам раскрыть, если я не понимаю что в итоге вы хотите услышать. )

vvn_black ★★★★★
()
Ответ на: комментарий от Reptile

должны быть зашифрованы или замаскированы (одним словом обезличены)

Заканчивай уже с изобретением своих терминов. Обезличивание это вообще про другое. Во всяком случае, ни разу не видел этот термин в контексте криптографии.

anonymous
()
Ответ на: комментарий от Reptile

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

Алгоритм AES с ключом 256 бит и правильно выбранным режимом работы делает бессмысленными любые попытки подбора ключа на нынешнем оборудовании. Всё, остальная мишура погоды не делает.

anonymous
()
Ответ на: комментарий от vvn_black

Каждый знает, что такое недоразумение. Скажем, договорились два человека встретиться в девять, но один понял так, что встреча назначена на девять часов утра, а другой – на девять вечера, и встреча не состоялась. Потом оба оправдываются: «Произошло недоразумение» или же «Получилось недоразумение». Будто бы оно происходит само по себе или его получают по почте как какое-нибудь неожиданное и неприятное известие.

Коротко о главном.

Штааа-а-а-а, это пишет человек, который на предыдущей странице заявлял

Это уже даже грустно. Ставить в пример собственную ошибку, которую я просто повторил. Вы в посте, на который я тогда отвечал, зачем-то поменяли смысл задом наперед и стали мне доказывать, что TLS есть без HTTPS, при том, что я говорил о передаче через HTTPS, при которой TLS тупо неотделим, иначе будет HTTP, следовательно и «HTTPS без TLS» и «TLS без HTTPS» - одно и тоже (неотделимы) в контексте примеров, которые я приводил, т. к. речь шла о передаче зашифрованных данных. Но вы вклячили новый контекст и приписали его мне. Мощь.

Вооооот. ) Потому что у вас всё очевидно

А вот это уже… интеллектуальная немощь? :D Каким образом из того, что я не понял вас, следует то, что мне «всё» очевидно?

а то и «криптографический алгоритм - лишь часть протокола, он же не работает отдельно».

Вам необходимо проверить регистры памяти. Наверно. Я так думаю) Помнится вы самолично утверждали, что протокол может и не использовать криптографию. Ух… ржака. Если вы начнете мне рассказывать, что протокол шифрования (он же «криптографический протокол») таки работает отдельно, то вы опять проявите свою истинную мощь - подмену чужого контекста своим. И тут даже не знаю, ржать мне в голос или биться головой об стену.

Какую точку зрения вам раскрыть, если я не понимаю что в итоге вы хотите услышать. )

Хотя бы инфу об «оглашенных» протоколах выше))

Reptile
() автор топика
Ответ на: комментарий от anonymous

Заканчивай уже с изобретением своих терминов. Обезличивание это вообще про другое. Во всяком случае, ни разу не видел этот термин в контексте криптографии.

Тут должна быть шутка из дмб)

Ммм… дорогие мои господа, вам необходимо разговаривать с википедией и восхищаться GPT4, а не общаться с людьми. Бедный неосведомленный пользователь бы помер от уровня формализма. А мне ещё говорят, что я слишком обобщёно мыслю…

Что ж, напоследок:

  1. Изи: Какой контекст наиболее вероятен для этих терминов?
  2. Мидл: Что среднестатистический пользователь понимает под термином «VPN»
  3. EXTREME: Существует ли гипероним к этому списку терминов? Звонок другу:

Термин «зверь» является гиперонимом по отношению к термину «собака», а термин «собака» в свою очередь — гиперонимом по отношению к термину «бульдог».

Список:

  • Шифрование
  • Криптография
  • Обезличивание
  • Маскировка
  • Обфускация
  • Инкапсуляция
  • Мимикрия
  • Децентрализация
  • Проксирование

Посмотрим кто, как и где договорился встретится) Чую захватывающий дискурс!

Reptile
() автор топика

Интересные точки зрения.

One-time pad, разумеется. При правильном использовании взлом в принципе невозможен.

Самым безопасным протоколом шифрования я считаю шифроблокноты с одноразовыми ключами.

Использовать то, что рекомендуется официальными реализациями. Не использовать те алгоритмы, которые явно обозначены ими как небезопасные. Но если очень надо для совместимости, то можно. В OpenSSH устаревшие алгоритмы и типы ключей нужно включать руками. Разработчики уже обо всём подумали, лучше ты не сделаешь.

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

Если передавать котиков, то никто не будет тратить сотни долларов на расшифровку, а если передавать ключи от биткоинов стоимостью в пару миллионов баксов, то будет. Если передавать что-то, что надо скрыть от правительства США, неплохо бы не пользоваться сертификатами и/или шифрами, выданными или разработанными подконтрольными США организациями и переходить на GPG или ещё что-то. А если передавать что-то, что надо скрыть от пацанов в соседнем дворе, то вполне достаточно пляшущих человечков.

Эх, теоретики. Просто ключ делится на две части, которые даются двум хранителям.

Самым безопасным является Шифр Вернама с ключами, сгенерированными с помощью истинной случайности (например, используя квантовые флуктуации). Вне зависимости от того, что я или кто-то другой там «считает».

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

Алгоритм AES с ключом 256 бит и правильно выбранным режимом работы делает бессмысленными любые попытки подбора ключа на нынешнем оборудовании. Всё, остальная мишура погоды не делает.

«Вот это поворот».

Не считаю протоколы шифрования безопасными

Reptile
() автор топика
Ответ на: комментарий от Reptile

Ну это же баян… когда стоит вопрос о защите данных

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

те, кто эти данные защищает, в последнюю очередь думают о электроэнергии))

Расскажите это майнерам.

bugfixer ★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от Reptile

То бишь я исходил из того, что данные будут изначально интересны, так как подвергаются высокой степени обезличивания.

Кому интересны обезличенные данные? О_О

Aceler ★★★★★
()