Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 132
Симметричное шифрование используется что бы потом кому надо удобней расшифровывать было?
Открытые ключи еще в институте не проходили?
Открытые ключи еще в институте не проходили?
Ну подразумевается что вы открытыми ключами передаете ключ для симметричного шифрования и дальше поток уже AES шифруется. Дорого же. Правда на двух трех строчных сообщениях наплевать конечно.
Недавно сам о таком подумывал, но потом пришел к выводу, что социальные сети и безопасность несовместимы, как ни шифруй. Но всё же.
По-моему, обмен ключами можно полностью автоматизировать при помощи алгоритма Диффи-Хеллмана. Также стоит отделить передачу шифрованных сообщений от их хранения (при передаче шифруем сессионным ключом, и при хранении храним локально и/или в удаленных бекапах используем гибридное шифрование RSA и AES). От MiTM при первом контакте двух людей защититесь через подтверждение короткого контрольного числа (как в Gajim сделано). При последующих контактах люди знаю публичные ключи RSA друг друга и тут всё понятно. Ключ RSA стоит бекапить удаленно в несколько мест в зашифрованном виде (пароль знает пользователь). А ещё хорошо бы скрывать от соц.сети факт использования шифрования при помощикотографии стеганографии.
Проще и безопаснее, однако, использовать torchat, если считать, что за Tor не наказывают.
PS. Не путайте расшифровку и дешифровку, пожалуйста.
По-моему, обмен ключами можно полностью автоматизировать при помощи алгоритма Диффи-Хеллмана. Также стоит отделить передачу шифрованных сообщений от их хранения (при передаче шифруем сессионным ключом, и при хранении храним локально и/или в удаленных бекапах используем гибридное шифрование RSA и AES). От MiTM при первом контакте двух людей защититесь через подтверждение короткого контрольного числа (как в Gajim сделано). При последующих контактах люди знаю публичные ключи RSA друг друга и тут всё понятно. Ключ RSA стоит бекапить удаленно в несколько мест в зашифрованном виде (пароль знает пользователь). А ещё хорошо бы скрывать от соц.сети факт использования шифрования при помощи
Проще и безопаснее, однако, использовать torchat, если считать, что за Tor не наказывают.
PS. Не путайте расшифровку и дешифровку, пожалуйста.
А можно для новичков поподробнее в чём отличие? Или имеется в виду, что расшифровкой занимается тот, кому адресовано сообщение, а дешифровкой неприятель?
Бытует мнение, что расшифровка — это получение доступа к исходному сообщению при помощи ключа и штатного алгоритма расшифровки, а дешифровка — это получение доступа к исходному сообщению методом взлома алгоритма или его реализации, не имея ключа.
Верно. При расшифровывании расшифровывающая сторона знает алгоритм расшифровывания и ключ, а при дешифровании неизвестен ключ и/или алгоритм. Дешифрованием занимается не обязательно неприятель, это может быть, например, исследователь, изучающий тексты на древнем неизученном языке.
по поводу асимметричного шифрования и открытого ключа:
в той же самой статье есть момент:
Протокол Диффи — Хеллмана отлично противостоит пассивному нападению, но в случае реализации атаки «человек посередине» он не устоит.
автоматизировать перехват ключей и программно реализовать посредника посередине для администрации вконтакта достаточно просто, если реализовывать передачу открытого ключа через другой сервер, то я пожалуй не знаю таких вариантов, где можно это реализовать, чтоб это было абсолютно прозрачно и не ангажированно в пользу анб. фсб. и т.д.
а так риск есть только в случае перехваты нажатия клавиатуры. или перехвате информации из браузера.
в той же самой статье есть момент:
Протокол Диффи — Хеллмана отлично противостоит пассивному нападению, но в случае реализации атаки «человек посередине» он не устоит.
автоматизировать перехват ключей и программно реализовать посредника посередине для администрации вконтакта достаточно просто, если реализовывать передачу открытого ключа через другой сервер, то я пожалуй не знаю таких вариантов, где можно это реализовать, чтоб это было абсолютно прозрачно и не ангажированно в пользу анб. фсб. и т.д.
а так риск есть только в случае перехваты нажатия клавиатуры. или перехвате информации из браузера.
Чтобы нельзя было реализовать атаку «Человек посередине», нужно использовать контрольное число, которое сверяется обоими собеседниками по защищенному (или хотя бы независимому каналу). В роли такого канала может выступать телефонный звонок, смс или чат на стороннем сервисе. Подслушивание обмена контрольным числом ничего не даст атакующему, для успешной атаки нужно подменить само число при обмене им собеседников, чтобы им казалось, что оно совпадает, а это значит подделать число в телефонном разговоре или в стороннем чате!
Такая схема используется в Gajim. При переходе в защищенный режим обоим собеседникам выводится на экран число, которое они должны сравнить и подтвердить, что оно совпадает. Думаю, это число является производным от ключа, полученного в результате Диффи — Хеллмана. Если человек влез посередине, то ключи, которыми шифруется соединение к двум собеседникам, будут различаться (так как «человек» не знает секретных составляющих, используемых собеседниками при обмене), значит и контрольные числа будут разными.
Такая схема используется в Gajim. При переходе в защищенный режим обоим собеседникам выводится на экран число, которое они должны сравнить и подтвердить, что оно совпадает. Думаю, это число является производным от ключа, полученного в результате Диффи — Хеллмана. Если человек влез посередине, то ключи, которыми шифруется соединение к двум собеседникам, будут различаться (так как «человек» не знает секретных составляющих, используемых собеседниками при обмене), значит и контрольные числа будут разными.
Для большей безопасности можно передавать шифрованные сообщения через одноразовые сервисы. Например через этот https://noref.org. Можно отправлять ссылки или сообщения, которые после прочтения адресатом сразу удаляются навсегда.
Это шутка была, да?
Или вы имеете в виду отправлять уже зашифрованный текст?
Или вы имеете в виду отправлять уже зашифрованный текст?
>«которые после прочтения адресатом сразу удаляются навсегда»
Да-да, конечно :) Точно так же, как удаляются аккаунты, фото и сообщения из Вконтакте ;)
Да-да, конечно :) Точно так же, как удаляются аккаунты, фото и сообщения из Вконтакте ;)
Имеено поэтому, на мой взгляд, такой сервис должен быть free and open source software — чтобы, во-первых, можно было убедиться, что там нет никаких хитростей, а во-вторых — чтобы можно было поднять свой инстанс, с блекджеком и шлюхами для уверенности.
Каким бы не был открытый и изученный код, он не гарантирует что именно ОН в не измененном виде запущен на удаленной машине. нет никакой возможности гарантировать что какая либо информация будет удалена на не подконтрольной вами машине.
Мне тоже приходила эта мысль в голову, когда я писал свой аналог этого сервиса. В принципе, проблема решаема, либо нужно запускать сервис у себя (ради чего я аналог и написал), либо шифровать всё на стороне клиента и ключ включать в хеш URL'а, чтобы он не попадал на сервер (или всё равно попадет?). В сервисе MEGA второй способ используется.
чтобы можно было поднять свой инстанс, для уверенности.
Я сделал free and open source аналог этого сервиса. Код, чтобы запустить у себя. Для сборки у себя потребуются boost, Wt, wt-classes (моя библиотека). Особенности: можно определять срок хранения текста; открытый текст хранится в памяти сервера, но не сохраняется на жесткий диск (разве что в своп). Если кто-то решит пользоваться через мой сервер, там возможен https-доступ с самоподписанным сертификатом.
Можно улучшить внешний вид этого приложения и запустить свой полноценный аналог noref.org.
Можно улучшить внешний вид этого приложения и запустить свой полноценный аналог noref.org.
> безопасность
> сторонние сервисы
Чего-то я в этом не понимаю…
> сторонние сервисы
Чего-то я в этом не понимаю…
Держите «плюс» за сервис. Как дополнительный канал защиты от всяких ботов Скайпа, в принципе, подойдёт. Ещё бы была открытая и свободная реализация такого, чтобы можно было у себя на сервере поднять…
Для Safari такое сделаете? Буду рад попробовать.
Было интересно, как реализовали AES. Сначала расстроился, когда увидел готовую библиотеку, потом обрадовался, увидев это:
//test crypting
//var decrypted = CryptoJS.AES.decrypt('U2FsdGVkX18WBLimtd4dQoHYNlRwOHZmUQxi4PwYzUk=', '777')
//alert(decrypted.toString(CryptoJS.enc.Utf8));
//test crypting
//var decrypted = CryptoJS.AES.decrypt('U2FsdGVkX18WBLimtd4dQoHYNlRwOHZmUQxi4PwYzUk=', '777')
//alert(decrypted.toString(CryptoJS.enc.Utf8));
До этих сервисов еще нужен анонимный канал с анонимным компом в анонимном месте на анонимной планете.
и два собеседника-анонима, не знающие ни друг друга, ни сами себя.
Почему-то всё мыслится как-то полярно: либо информация такая, что её защищать вообще ни от кого не нужно, либо желающие получить информацию — могущественные боги. Есть же масса промежуточных вариантов включающих помимо прочего коммерческую тайну, которые могущественным противникам могут быть не интересны, а от «конкурентов»/«недоброжелателей», способных вклиниться в канал связи (не такой уж и защищённый на данный момент), защитить хотелось бы. Да и с государствами всё не так уж и однозначно, иначе бы режимы не сменяли друг друга на наших глазах.
Для промежуточного варианта есть VPN, SSL (https) и прочее шифрование, если уж надо скрыть. Но и в этом случае фигня — передаете вы по супер защищенному протоколу документ, а на другой стороне блондинка с завирусованным компом это добро получает. И толку от всей этой секретности и шифрования? (не говоря уже о том что на сервере третьего лица ваш документ мог сохраниться).
Я думаю, это, в принципе, реализуемо. Например, предположим, есть сервис, где любой может публиковать анонимно зашифрованные сообщения небольшой длины. И никто не будет знать кто и что там опубликовал. Но тот, кто ждёт сообщения от своих партнёров закачивает эти сообщения (всё) на свой комп и последовательно пытается расшифровать каждое из них своим ключом. Те, что, расшифровываются — Ваши. Остальные — игнорируются. Минус — в трафике, но зато и анонимность и защита — всё как Вы хотите. Кроме того, возможно со временем, такие доски с объявлениями будут на всех сайтах.
Случайно промахнулся и поставил вам «минус» вместо «плюса». Извините, пожалуйста. ^_^
Кстати, в этот концепт можно добавить стеганографию, а сам сервис делать в виде хаба для картинок с котятками, скажем.
BitMessage работает именно так.
«Никто не будет знать», «анонимно оставляют» — вы неисправимый оптимист, и вот почему: сервис может быть открыт заинтересованными лицами, знающими толк в сборе информации или продающими информацию (особенно, если это станет популярно, как Вы ожидаете), админов сервиса или хостера можно купить/взять за яйца, операционную систему можно взломать чуть ли не через мышку, а в массе квалификация персонала не может быть везде исключительно высокой (ага, язвили тут некоторые на тему серверов с мышками )).
В этом вопросе меня больше всего умиляют списки «анонимных» прокси, за которыми народ так бегает в интернете не задумываясь о журналах и интересах владельцев этих серверов и поиск «подверженных уязвимости» серверов для создания себе такого прокси. С учётом того, что в своё время была продемонстрирована возможность перехватить информацию в tor'е, всего лишь внедрив в сеть несколько своих серверов, надеяться на анонимность в сети — несколько,… ммм, удивитетельно.
Доверять нельзя даже себе, а тут целый сервис + хостинг + ISP, имеющие возможность журналировать трафик… Впрочем, как бизнес-идея — очень даже ничего :-)
В этом вопросе меня больше всего умиляют списки «анонимных» прокси, за которыми народ так бегает в интернете не задумываясь о журналах и интересах владельцев этих серверов и поиск «подверженных уязвимости» серверов для создания себе такого прокси. С учётом того, что в своё время была продемонстрирована возможность перехватить информацию в tor'е, всего лишь внедрив в сеть несколько своих серверов, надеяться на анонимность в сети — несколько,… ммм, удивитетельно.
Доверять нельзя даже себе, а тут целый сервис + хостинг + ISP, имеющие возможность журналировать трафик… Впрочем, как бизнес-идея — очень даже ничего :-)
В плане анонимности я имел в виду, что трудно связать тот факт, что именно моё сообщение адресовано именно Вам. Ну и, конечно, если таких досок объявлений будет много, то отследить мою активность (а у меня есть комп дома, на работе, у друзей, можно пойти в Интернет-кафе, где стоит их компьютер и т.д.) будет очень сложно. Поймите меня правильно, если я, условно говоря, террорист, то меня скорее всего, будут пасти очень умело и каждый мой шаг будет под колпаком. Но если я ничего особого из себя не представляю, то мне зашифроваться от жены, родственников или просто конкурентов будет вполне по силам. (Даже если они хорошие компьютерные спецы.)
Так ведь недавно всплыло, что АНБ щёлкает информацию, зашифрованную AES, как орехи? Предыстория, если я ничего не путаю, такова: АНБ объявило конкурс на лучший алгоритм шифрования под названием AES, в итоге отобрали наименее криптостойкий и назвали его так же как и конкурс.
SHA-1 и SHA-2, кстати были разработаны в АНБ.
SHA-1 и SHA-2, кстати были разработаны в АНБ.
А я еще слышал, что Обама стал убийцей.
АНБ объявило конкурс на лучший алгоритм шифрования под названием AES, в итоге отобрали наименее криптостойкийАга, и теперь шифруют все свои государственные секреты наименее стойким алгоритмом.
AES входит в Suite B, но у них есть еще и Suite A, который
used for the protection of some categories of especially sensitive information (a small percentage of the overall national security-related information assurance market)И эти алгоритмы секретны.
Но ведь это Security through obscurity. К AES и то больше доверия, чем к неизвестным алгоритмам, непонятно кем изобретенным и особо никем не проверенным.
Открытость и относительно большой возраст алгоритма AES, в общем-то, дает достаточно оснований для того, чтобы считать его достаточно надежным для личного использования.
Открытость и относительно большой возраст алгоритма AES, в общем-то, дает достаточно оснований для того, чтобы считать его достаточно надежным для личного использования.
Я к тому что не все государственные тайны они шифруют AES, есть у них и свои секретные алгоритмы. И это не security through obscurity, у них есть ученые которые проверяют что алгоритмы надежны, просто не раскрывая их они добавляют лишний уровень защиты.
P. S. Это совершенно не значит, что AES не стойкий.
P. S. Это совершенно не значит, что AES не стойкий.
То есть, вы априори доверяете всему, к чему АНБ приложит руку, до тех пор, пока лично не увидите разоблачающие документы от, скажем, Сноудена? Потому что это для вас показатель качества от государства?
В недавней новости была информация о том, что они без труда дешифруют SSL, цитата:
А SSL может использовать шифрование, в том числе, и AES. Из чего можно сделать вывод, что методика передачи данных, описанная выше, уже не гарантия безопасности — кто может гарантировать, что третья сторона, подтверждавшая сертификат, не слила в АНБ данные, помогающие дешифровке? Никто.
В недавней новости была информация о том, что они без труда дешифруют SSL, цитата:
АНБ поддерживает внутреннюю базу данных ключей шифрования, позволяющую мгновенно расшифровывать соединения.
А SSL может использовать шифрование, в том числе, и AES. Из чего можно сделать вывод, что методика передачи данных, описанная выше, уже не гарантия безопасности — кто может гарантировать, что третья сторона, подтверждавшая сертификат, не слила в АНБ данные, помогающие дешифровке? Никто.
То есть, вы априори доверяете всему, к чему АНБ приложит руку, до тех пор, пока лично не увидите разоблачающие документы от, скажем, Сноудена?Нет, я лишь подвергаю сомнению тот факт, что стандартом шифрования для своей же секретной информации (пусть и не всей, но части) АНБ могло выбрать наименее стойкий алгоритм.
А ведь могут же. Они до последнего момента были уверены, что никто кроме них не знает изъяны алгоритмов, которые они проталкивали в стандарты (и речь сейчас не только и не столько об AES). Кого им бояться, что расшифруют — себя, что ли? Поэтому так и заволновались, когда Сноуден пообещал всем рассказать как у них всё работало — на кону могут стоять не только документы, которыми располагает Сноуден, но и все остальные, какие могут попасть не в те руки в будущем. Но это я уже так, теоретизирую.
Они до последнего момента были уверены, что никто кроме них не знает изъяны алгоритмов, которые они проталкивали в стандартыЭто вполне может быть справедливо, если речь идет об алгоритмах Suite A, которые они никому не показывают, дабы никто и не смог их исследовать. Но надеяться, что никто в мире за долгие годы не найдет бэкдор или уязвимость в открыто опубликованном алгоритме? Нет, конечно, в этом мире всякое бывает, но чтобы так…
«Заволновались»
Хм, что и кому рассказал Сноуден и что об этом написали — абсолютно разные люди.
Может он секретные ключи сдал? Кто угодно заволновался бы ))
Хм, что и кому рассказал Сноуден и что об этом написали — абсолютно разные люди.
Может он секретные ключи сдал? Кто угодно заволновался бы ))
Как связано наличие базы ключей с надежностью самого алгоритма? Если у АНБ есть ключ, то они что угодно расшифруют — хоть одноразовый шифроблокнот.АНБ поддерживает внутреннюю базу данных ключей шифрования, позволяющую мгновенно расшифровывать соединения.А SSL может использовать шифрование, в том числе, и AES.
Из чего можно сделать вывод, что методика передачи данных, описанная выше, уже не гарантия безопасности — кто может гарантировать, что третья сторона, подтверждавшая сертификат, не слила в АНБ данные, помогающие дешифровке?А где в описанной методике третья сторона и сертификаты? Автор утверждает, что ключами лучше всего обменяться при личной встрече.
хорошая пища для размышлений. нет ссылок по сабжу? про анб и аес
Ассиметричное шифрование и PGP вам в помощь. AES для таких вещей не особо подходит, ИМХО.
Ещё можно воспользоваться советом из комментария mizi и сделать отключаемую функцию автоматической генерации таких одноразовых ссылок через сервисы и автоматического же получения из них данных.
Ещё можно воспользоваться советом из комментария mizi и сделать отключаемую функцию автоматической генерации таких одноразовых ссылок через сервисы и автоматического же получения из них данных.
AES один из алгоритмов шифрования который используется в PGP
про одноразовые ссылки интересная идея
про одноразовые ссылки интересная идея
Благодарю, прочитаю как-нибудь на досуге, наверное.
Благодарю ещё раз, прочитал. Великолепное обоснование, благодарю. Пока что, меня смущает в OTR только отсутствие возможности выбрать другой симметричный алгоритм — в этом документе указано, что они используют AES.
В crypto-js выбор-то невелик — AES, 3DES, Rabbit, RC4. Думаю, что без проблем можно было бы использовать один из них, но это если точно быть уверенным, что при этом общая схема не пострадает, а в этом никогда нельзя быть уверенным.
А что, в JS сейчас настолько всё с криптографией печально, что существует только одна, ни разу не расширяемая библиотека?
Есть ещё несколько библиотек: scrypt, RSA, в том числе и EC, и ещё несколько библиотек на основе этой, интерфейс для работы с клиентскими сертификатами + random, OpenPGP. Больше вроде как ничего толкового нет. Ни OTR, ни поддержки аппаратного ускорения за счёт предоставления браузером интерфейсов к OpenSSL, ни уж пост-квантумной криптографии. Есть ещё NaCL-js, но не было времени посмотреть. А в том же crypto-js постоянно обнаруживаются какие-то баги, то AES оказался 128бит, то в режиме CTR какие-то дыры. Ну, и random'а-то нет как такового в общем.
Считаете, что путь вашего сообщения до сервера вконтакте безопасный?
Как раз не считает — поэтому и шифрует на клиенской стороне с помощью JS. End-to-end encryption получается.
На незащищенной операционке и канале связи? А наверняка ведь и обновленьица включены, другие программы стоят?
На незащищенной операционке
Это ещё почему? В любом случае, взломать ОСь — это уже активное вмешательство. И оно заметно дороже простой пассивной слежки путём просмотра трафика, да ещё и требует заточки под конкретную машину и её способы защиты.
канале связи
Эмм… Вообще-то, шифрование и ЭЦП как раз и применятся для защиты этого самого канала связи. ^_^
А наверняка ведь и обновленьица включены
Нет, обновляю по желанию.
другие программы стоят?
AppArmor, SELinux, виртуализация?
Вы бы ещё дальше пошли: на американских чипах? в этой вселенной?
Абсолютной защиты не бывает. Бывает защита, вскрытие которой нецелесообразно, ввиду дикого соотношения усилий и результата. На это и рассчитаны меры по увеличению безопасности.
А зачем взламывать Ось? Слышали, правительства недавно предостерегали от использования Windows 8? Она была не взломана, а изначально поставлялась с дверцей.
А зачем взламывать Ось? Слышали, правительства недавно предостерегали от использования Windows 8?
Кроме Windows сущесвует множество других ОС. ;)
Если гарантируете отсутсвие вредоносных кодов, бэкдоров, троянов и прочей ерунды, тогда проблем нет.
Я — не гарантирую. И никто не гарантирует. Однако, доверие к мейнтейнерам того же Debian или Arch Linux гораздо больше, чем к MS. Код ядра и базового набора проверяется многими независимыми разработчиками, что заметно увеличивает вероятность, что там нет «вредоносных кодов, бэкдоров, троянов и прочей ерунды». Хотя, факапы бывают у всех.
Все остальные приложения всегда можно контролировать, помещать в песочницы, выделять им права только на необходимые действия, etc. Тут уже помогут упомянутые мной apparmor, selinux и/или виртуализация (qemu+kvm, xen, etc.).
Более того, конкретно я или вы всегда можете при желании взять исходники и посмотреть, всё ли в порядке.
Все остальные приложения всегда можно контролировать, помещать в песочницы, выделять им права только на необходимые действия, etc. Тут уже помогут упомянутые мной apparmor, selinux и/или виртуализация (qemu+kvm, xen, etc.).
Более того, конкретно я или вы всегда можете при желании взять исходники и посмотреть, всё ли в порядке.
конкретно я или вы всегда можете
… конкретно я или вы всегда можем…
Если не гарантируете, то любая другая самая защищенная защита может оказаться бесполезной, если хотя бы одно звено находится под вопросом. Когда Вы доверяете чему-то больше, чем другому лишь на оценках и предположениях, то разговор о защите не будет отличаться от аргументов вроде «да кому мы нужны» или «кто захочет нас взломать?» и т. п.
Если не гарантируете, то любая другая самая защищенная защита может оказаться бесполезной, если хотя бы одно звено находится под вопросом
Понятное дело, что защищенность всей системы равна защищённости наименее защищённого её компонента. Другое дело, что самостоятельно (в одиночку) гарантировать защищённость сложной системы с таким количеством компонентов и объёмом исходников… скажем так, проблематично.
Когда Вы доверяете чему-то больше, чем другому лишь на оценках и предположениях,
Моё доверие основывается на таких фактах, что:
0. код, поступающий в ядро, coreutils, и прочие компоненты базового набора проверяется:
* разработчиками конкретного компонента
* мейнтейнером этого компонента в дистрибутиве
* при установке пакета я проверяю подпись ментейнера
1. каждый из этих этапов можно проверить
* код компонента можно просматривать и тестировать самостоятельно
* компоненты можно собирать самому, дабы увериться, что мейнтейнер не внёс туда вредоносного кода
* подпись — гарантия, что пакет с компонентом не был изменён по пути ко мне
Причём, если серьёзно задаться задачей провалидировать базовую систему, я считаю, что это по силам не очень большому коллективу хорошо разбирающихся в вопросе программистов, с учётом возможности отключения/исключения из исходников не требуемого функционала.
Но это просто размышления. С другой стороны, мне не понятен ваш принцип «если где-то косяк, то можно забить на всё». Он чем-то схож, на мой взгляд, с «феноменом битых окон».
Построение защиты начинается с определения векторов атаки. Я согласен с утверждением, что закрывать нужно все сразу, но среди них всё равно есть более и менее вероятные или затратные.
Например, речь идёт о конфиденциальности сообщений. Для конкретики давайте представим, что моих, кому-нибудь из друзей, отправляемых через ВКонтакте.
* Вариант с отсутствием шифрования: сидим и смотрим. Причём для этого не обязательно быть владельцем сервера, можно просто быть работником провайдера или подключиться в линию. Подсматривающие: ФСБ, администрация ВКонтакте, кто угодно.
* Вариант с HTTPS до сервера: прочитать сообщения теперь может администрация контакта. (атаки на HTTPS вроде mitm с корректно подписанным каким-нибудь CA сертификатом не учитываем, для упрощения) Подсматривающие: ФСБ, администрация ВКонтакте.
* Вариант с PGP (без или с https — всё равно): теперь моё сообщение может прочитать только адресат. Для того, чтобы кто-нибудь другой его прочитал, ему потребуется взломать мою или адресата систему или иметь доступ к какому-нибудь скрытому в Linux'е бэкдору. Подсматривающие: ФСБ?
Заметная разница, не так ли?
Нельзя никому доверять, верить или не верить, думать, проблематично это будет или нет. Только гарантированная защита решит проблему. Иначе это будет не защита, а игра в защиту.
У вас есть примеры полностью гарантированной защиты?
Ну это же элементарно. Стучите на клаве уже зашифрованный текст, и шлете куда угодно и как угодно.
*не в ту ветку*
Вы гарантируете, что алгоритм шифрования, который вы используете, достаточно криптостойкий?
Есессно.
Пример?
Ну и дальше, прогнозируя возможные вектора атаки на вашу «гарантированную» защиту:
* Вы гарантируете, что ключ никому больше не известен? Что, например, у вас или получателя его не подсмотрят?
* Вы гарантируете абсолютную стойкость к ректотермальному криптоанализу и у себя, и у получателя?
Ну и дальше, прогнозируя возможные вектора атаки на вашу «гарантированную» защиту:
* Вы гарантируете, что ключ никому больше не известен? Что, например, у вас или получателя его не подсмотрят?
* Вы гарантируете абсолютную стойкость к ректотермальному криптоанализу и у себя, и у получателя?
Эти вопросы уже из другой области и они решаются слишком разнообразно.
Почему же? Они тоже влияют на безопасность.
Вообще, я это к тому, что абсолютной защиты не существует, и гарантировать её невозможно. Вы можете перекрывать определённые векторы атаки, можете даже попробовать гарантировать это «покрытие». Но никто вам не даст гарантии, что вы предусмотрели и перекрыли их все, да ещё и полностью.
Вообще, я это к тому, что абсолютной защиты не существует, и гарантировать её невозможно. Вы можете перекрывать определённые векторы атаки, можете даже попробовать гарантировать это «покрытие». Но никто вам не даст гарантии, что вы предусмотрели и перекрыли их все, да ещё и полностью.
Э… ну, пришли к Штирлицу гестаповцы, а он уже съел шифровку. И что они будут делать?
Если он её помнит, то попросят поделиться, очевидно же.
Абсолютно криптостойкий человек и одноразовые блокноты — это уже близко к абсолютной защите. Но тут тоже есть варианты:
0. Перехват + атака на ключ — можно скопировать эти одноразовые блокноты. Требует заполучения к ним физического доступа. Не работает, если ключи в голове у человека — см. следующий пункт.
1. Человек. Сейчас существует довольно большое количество разнообразных психоделических препаратов — я почти уверен, что способ извлечь информацию из него можно найти, при большом желании. Это ни разу не гуманно, в большинстве стран — незаконно, но не везде (Привет, США! Как там твой «Акт Патриота»?)
То есть, даже в такой схеме, присутствует фактор человеческой физиологии.
0. Перехват + атака на ключ — можно скопировать эти одноразовые блокноты. Требует заполучения к ним физического доступа. Не работает, если ключи в голове у человека — см. следующий пункт.
1. Человек. Сейчас существует довольно большое количество разнообразных психоделических препаратов — я почти уверен, что способ извлечь информацию из него можно найти, при большом желании. Это ни разу не гуманно, в большинстве стран — незаконно, но не везде (Привет, США! Как там твой «Акт Патриота»?)
То есть, даже в такой схеме, присутствует фактор человеческой физиологии.
А если ключ у троих в разных местах? У каждого по ключику. Даже не по ключику, а по ключику к ключику.
Тогда как кто-то один получит ключ для расшифровки?
В любом случае, всегда можно найти всех тех троих, а дальше — см. пункт 1 из моего поста.
Вопрос только во времени, средствах и возможностях.
В любом случае, всегда можно найти всех тех троих, а дальше — см. пункт 1 из моего поста.
Вопрос только во времени, средствах и возможностях.
Найти всех троих? Они же в разных местах. К тому же один из них на станции МКС. Пока привезут грузовик с психоделиками, актуальность уже пропадет. :)
актуальность уже пропадет. :)
Как я и говорил, «вопрос только во времени, средствах и возможностях».
(offtopic) Я так погляжу, у вас сегодня явно выходной и жесткое желание придумать какую-то абсолютную защиту. Почему бы тогда не сказать, что ключ у супер-героя, который стреляет молниями из глаз, никогда не спит, не имеет родных, писает психоделиками и умеет телепортироваться в любое произвольное место по своему желанию? Тогда ему никакие спецслужбы не страшны, да.
да, именно так.
Идея, в общих чертах, нормальная, но даже при беглом просмотре кода заметно несколько ошибок в криптографии.
Вы не используете аутентификацию. Это значит что любой может отправлять сообщения якобы зашифрованные отправителем. Более того, можно менять текст уже зашифрованных сообщений. Лучше бы вам использовать HMAC из библиотеки CryptoJS или, скажем, GCM или OCB режимы из sjcl.
OpenSSL KDF, которая используется по умолчанию не рекомендуется к использованию даже самим OpenSSL:
P.S. Вместо alert используйте console.log(), намного удобнее.
Вы не используете аутентификацию. Это значит что любой может отправлять сообщения якобы зашифрованные отправителем. Более того, можно менять текст уже зашифрованных сообщений. Лучше бы вам использовать HMAC из библиотеки CryptoJS или, скажем, GCM или OCB режимы из sjcl.
OpenSSL KDF, которая используется по умолчанию не рекомендуется к использованию даже самим OpenSSL:
Newer applications should use more standard algorithms such as PBKDF2 as defined in PKCS#5v2.1 for key derivation.Используйте PBKDF2, тем более что она доступна в CryptoJS.
P.S. Вместо alert используйте console.log(), намного удобнее.
Что-то мне подсказывает, что цели такой и не ставилось. Была решена только одна проблема — не дать прочитать личную переписку при передаче её по каналам связи и возможном хранении на промежуточных серверах посторонним людям. Для вконтактика это сообщение будет выглядеть как бред, но с другой стороны сообщение будет сохранено и может быть прочитано теми кто знает необходимый ключ.
Это, пожалуй, одна из тех вещей в криптографии о которых даже рассуждать не нужно, нужно их просто использовать.
Информацию в процессе передачи можно изменить. Вы отправляете: «Встретимся в 18:00», я делаю XOR, получателю доходит «Встретимся в 21:00». И он не знает что его обманули! Где же защита информации? Я понимаю, автор не ставил задачу сделать суперзащищенный протокол, но аутентификация практически неотделима от шифрования.
Информацию в процессе передачи можно изменить. Вы отправляете: «Встретимся в 18:00», я делаю XOR, получателю доходит «Встретимся в 21:00». И он не знает что его обманули! Где же защита информации? Я понимаю, автор не ставил задачу сделать суперзащищенный протокол, но аутентификация практически неотделима от шифрования.
Задача ставилась «скрыть от глаз», чтобы вконтактик не подсмотрел и не мог использовать ваши данные. Аутентификация здесь работает стандартная — на уровне вконтакта, т.е. логин/пароль от аккаунта. Если логин пароль можно перехватить, так же можно перехватить и ключ. Смысла усложнять уже готовую аутентификацию здесь нет.
Нет, ключ «так же» перехватить нельзя. Смысл же в том чтобы передать ключ другим каналом, по телефону/при личной встрече, например.
Просто чтобы уточнить что под аутентификацией мы понимаем одно и то же: аутентификация зашифрованного сообщения — это способ удостоверится что сообщение дошло до получателя ровно в том виде, в котором мы его отправили — если это не так, вывести пользователю сообщение об ошибке.
Просто чтобы уточнить что под аутентификацией мы понимаем одно и то же: аутентификация зашифрованного сообщения — это способ удостоверится что сообщение дошло до получателя ровно в том виде, в котором мы его отправили — если это не так, вывести пользователю сообщение об ошибке.
Речь идет о человекочитаемом тексте, поэтому любые манипуляции над зашифрованными данными без знания ключа скорей всего приведут к слишком явному искажению текста. Вероятно поэтому автор и не стал ничего изобретать в этом направлении.
скорей всего приведут к слишком явному искажению текстаПроблема в том что это так только если текст менять случайно. Мне достаточно подсмотреть одно любое сообщение (т. е. получить текст и его шифр) и я смогу отправлять любые сообщения длиной 16 байт на свой выбор пока мне не надоест и получатель не будет знать о подмене.
для этого надо будет как минимум иметь доступ к компьютеру жертвы когда она просматривает сообщение, тут уж можно и сам ключик умыкнуть. А для отправки сообщения нужно взломать сам аккаунт собеседника. Худо-бедно эти направления прикрыты.
Худо-бедно эти направления прикрытыНу если они прикрыты (т. е. у злоумышленника нет ни доступа к аккаунту, ни доступа к компьютеру), то к чему тогда шифрование?
Реализовать все что я описал — 3-5 строчек, минусов — никаких, плюсы — очевидны. Что вы пытаетесь доказать?
Я пытаюсь донести то, что полумерам в шифровании нет места. На отсутствии аутентификации погорели многие (небольшой список с пруфлинками здесь — security.stackexchange.com/a/2206). И автор совершает ту же ошибку, однако предотвратить её элементарно.
вроде теперь можно и для FB такое сделать
Chrome-расширение mailvelope прекрасно работает с Вконтакте и Одноклассниками (но не с facebook). Исользуется ассиметричное шифрование с помощью ключей gpg.
Chrome-расширение mailvelope прекрасно работает с Вконтакте и Одноклассниками (но не с facebook).
Не проверял, жду расширения для лисы, тем временем пользуюсь kgpg и kleopatra.
www.openpgpjs.org/
Исользуется ассиметричное шифрование с помощью ключей gpg.
Ребят, а не является ли разработка и распространение криптоалгоритмов без лицензии ФСБ уголовно наказуемым? Или те времена прошли?
В России, по-моему, разрешено использование в личных целях. Интересно было бы пост на эту тему, конечно, увидеть, желательно — вместе с сравнением этого аспекта законодательства России, Украины (это лично мне ^_^), ЕС, США. =)
Статья 13.13 КоАП РФ. Но не уголовная, а административная.
А разве здесь есть разработка алгоритма? Разработка и реализация это не одно и то же всё таки.
Это использование алгоритмов, а не разработка. Тем более это не ГОСТ.
Такая защита вызвала у меня лично вот такую ассоциацию.
А вообще, на волне Сноудена и американских шпионов будет вполне востребовано, ибо у всех начинается паранойя на тему «кто смеет читать мои сообщения, ведь там много всего личного!». Вдумайтесь, действительно ли много у вас такого личного и есть ли за что просматривать ваши сообщения кому — то? Я, к примеру, могу обнародовать 95% своих диалогов, там нет ничего такого сверхсекретного.
Вы же в сообщениях вк не скидываете коды запуска атомных бомб? Are you?
А вообще, на волне Сноудена и американских шпионов будет вполне востребовано, ибо у всех начинается паранойя на тему «кто смеет читать мои сообщения, ведь там много всего личного!». Вдумайтесь, действительно ли много у вас такого личного и есть ли за что просматривать ваши сообщения кому — то? Я, к примеру, могу обнародовать 95% своих диалогов, там нет ничего такого сверхсекретного.
Вы же в сообщениях вк не скидываете коды запуска атомных бомб? Are you?
Я, к примеру, могу обнародовать 95% своих диалогов, там нет ничего такого сверхсекретного.
Именно из-за оставшихся пяти, одного или даже сотой части процента нужно шифровать все сообщения. Чтобы важные не выделялись в общем потоке, среди «приветкакдела?», «мимими» и фотографий котиков.
Потенциального врага, может интересовать доступ к остальным — ключевым — 5% ваших сообщений.
К высказавшимся добавлю, что при смене режима, то, что поощрялось обществом и «хоть щас всем покажу», внезапно становится смертельно опасным, наказуемым и прочия, прочия, прочия. Кроме того: «слово не воробей...», поэтому лучше не выпускать его на свободу, а аккуратно передать из рук в руки. А нужно было это «аккауратно» на самом деле или не очень, при незначительной стоимости аккуратности, дело десятое. Лучше сто раз мобилизовать оборону по ложной тревоге, чем один раз пропустить настоящую атаку.
А я просто не хочу показывать свою переписку. Не важно с кем и какую — абсолютно всю, просто не хочу. И поэтому буду всячески усложнять попытки прочитать мою переписку без моего ведома.
Перспективнее тогда уж Peer2Peer, благо WebRTC позволяет…
Код шифрования сообщений можно передать прям вконтакте используя например что-нить вроде такого сервиса onetimenote.com/
Зачем? Асимметричная криптография как раз для таких вещей создавалась.
Тсс — мой первый коммент про ассиметричную криптографию в глубоком минусе
Детям хочется именнно AES ))
Детям хочется именнно AES ))
Ваш комментарий в глубоком минусе скорее из-за формы и позиции «Все вокруг — мужеложцы, один я — Д'артаньян!». Там нет про ассиметричную криптографию ни слова — только наезд на автора за то, что он выбрал симметричную и предположения о его возрасте и образовании.
Я, кстати, тоже «минусанул», не смотря на то, что предпочитаю асимметричную (или гибридную, при больших объёмах данных) криптографию.
Благодарю вас — вы уверили меня в том, что ваш первый комментарий заминусовали не просто так. Продолжайте в том же духе.
Я, кстати, тоже «минусанул», не смотря на то, что предпочитаю асимметричную (или гибридную, при больших объёмах данных) криптографию.
Детям хочется именнно AES ))
Благодарю вас — вы уверили меня в том, что ваш первый комментарий заминусовали не просто так. Продолжайте в том же духе.
У меня пара вопросов
1 — Как передать ключик
2 — Зачем используется cryptoJS — где длина ключа 20 символов
1 — Как передать ключик
2 — Зачем используется cryptoJS — где длина ключа 20 символов
1. Гибридные системы так и поступают: берут контент, шифруют симметрично рандомно сгенерированным длинным ключем, ключ шифруют ассиметрично открытым ключиком получателя, соединяют и отправляют.
2. Да кто его знает-то. Я в комментариях оставлял ссылку на JS реализацию PGP: www.openpgpjs.org/.
2. Да кто его знает-то. Я в комментариях оставлял ссылку на JS реализацию PGP: www.openpgpjs.org/.
Поправлю ссылку: https://openpgpjs.org/
Ваша уже не работает.
А как удалить ключ? Меня не столько волнует, кто из ВК или ФСБ сможет читать мои сообщения, сколько то, кто сможет их читать получив доступ к моему компу. Кстати, а где хранится сам ключ? Я бы хотел иметь возможность ввести ключи, написать сообщения и удалить ключ. Когда захочу прочесть, введу ключ снова. А еще было бы прикольно, чтобы сообщения, которые показываются в зашифрованном виде, вместо набора символов преобразовывались в случайные фразы.
ключ нигде не сохраняется. вводить надо при каждом открытии страницы. чтобы его убрать. можно обновить страницу.
кстати хороший способ обезопасить свою переписку при доступе к компу посторонних лиц, шифровать её этим плагином.
в разные периоды времени можно использовать разные ключи (правда бывает один баг иногда).
кстати хороший способ обезопасить свою переписку при доступе к компу посторонних лиц, шифровать её этим плагином.
в разные периоды времени можно использовать разные ключи (правда бывает один баг иногда).
Изобретение велосипеда. Уже есть PGP же.
Нужная вещь для передачи в личных сообщениях ссылок, которые одноклассники или контакт вырезают нафиг.
Вот такой плагин для FireFox актуален?
https://addons.mozilla.org/ru/firefox/addon/vkencrypt/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Шифрования сообщений вконтакте методом AES для браузеров Chrome и Firefox