Системный архитектор, криптоманьяк
5,0
рейтинг
5 ноября 2013 в 09:04

Разработка → RSA Security заявила о наличии АНБ-бэкдора в своих продуктах


Причем, еще 19 сентября.
А вот Microsoft, например, не заявило. Но об этом ниже.

Итак, в их продуктах RSA Data Protection и RSA Bsafe во всю использовался алгоритм Dual EC_DRBG (Dual Elliptic Curve Deterministic Random Bit Generation), сертифицированный NIST (описание). И сертифицированный, как выяснилось, с сюрпризом от агенства национальной безопасности США. То есть, это никакой не random, если вы знаете в чём суть закладки.
Ну и о том, что этот алгоритм может содержать бэкдор, исследователи говорили еще в 2007м году. Что не помешало NIST его сертифицировать. А кипиш начался после опубликованных Сноуденом документов, где явно говорилось о неком стандарте 2006 года.

Dual_EC_DRBG, между прочим, является довольно популярной штуковиной.
Реализован в Windows, начиная с Vista SP1, что делает его самым популярным в мире. Так же, реализация есть в OpenSSL и вообще он похоже пролоббирован в куче продуктов (McAfee, например, но те использовали его только для программ гос сектора). Так что, вычищать от него код придется еще долгое время.

UPD
Из комментариев, подробности устройства бэкдора, практически на пальцах. (перевод)

UPD2
Список сертифицированных продуктов, так или иначе использующих этот алгоритм.
@Scratch
карма
101,7
рейтинг 5,0
Системный архитектор, криптоманьяк
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (89)

  • +86
    Молодец этот Сноуден, реальную пользу обществу принес.
    • +30
      В самом начале можно было часто слышать обвинения в капитанстве («Все и так знали, что за нами следят! Тоже мне открытие!»), но со временем заявления Сноудена всё чаще стали приводить к реальным последствиям. Интересно, сколько ещё у него тузов в рукаве.
      • +7
        Тузы в рукаве у АНБ, и их еще много.
    • +12
      Причём, похоже, от всего АНБ толку меньше, чем от него одного.
    • –9
      Ребята, я вот одного не пойму, тут же Хабр, для многих ли сливы Сноудена стали откровением?
      Да грошь цена была бы АНБ и иже с ними если бы они не творили то что творят, хотя они не делают ничего экстраординарного, ничего выдающегося, всё просто и очевидно и предсказуемо. Все кому есть что скрывать, давно в курсе векторов атак на приватность гражданина…
      И здесь, почти такая же история как в своё время с просушкой GSM, да A5/1 во истину уязвим, но кого колышет, если можно про лоббировать что бы ключики людям выдавались во вполне конкретных диапазонах значений, и зная эти диапазоны тупо слушать всех и вся методом простого перебора, без театра IMSI :-)

      Любой, даже самый устойчивый алгоритм шифрования не будет устойчив против навязанных дядями ключей!
      И качество random-а интересно не только матаникам-задротам но и компетентным органам, которые стараются это качество себе обеспечить насильно, один хрен никто ничего не анализирует ибо даже профессиональные исследователи безопасности не склонны к курению фундаментального матана, а там… Хотя именно там нас ждёт ещё много чего интересного…
      • +22
        До «сливов Сноудена» эти откровения были шредингеровскими, находились в квантовой суперпозиции: то есть мы, технари, знали, что реализовать все эти закладки — возможно. Но доказательств не было.
        А сейчас — все сомнения разрешились.

        Кот Надежда на лучшее — мертва.
        • +5
          Надежда Шредингера.
  • +23
    Кстати на crypto.stachexchange есть понятное объяснение, в чем состоит закладка.
    • +2
      спасибо за ссылку, ожидал хоть какой-то намек в статье увидеть, но увы.
      • 0
        Перевод статьи по ссылке. Появился на хабре после публикации текущего топика.
  • –5
    Код вычистится сам как только перестанем долларами пользоваться для оплаты.

    • +9
      хоть АНБ здесь — это конкретная организация, но я воспринимаю акт Сноудена — не камнем в огород политики США, а камнем в огород вообще избыточного государственного регулирования частной жизни граждан. 1984, как говорится, доллар здесь уже не определяющий фактор контроля. Свое АНБ есть в каждом королевстве.
  • +3
    В ecdsa ключах в openssh этот алгоритм используется?
    • +1
      Вроде бы он по умолчанию не используется
      • +2
        а в OpenVPN (OpenSSL)?
        • +1
          тоже
          • 0
            Спасибо, мой внутренний параноик успокоился, надеюсь на долго.
            • +7
              Нельзя его успокаивать, можно только давать передохнуть. Прикиньте, сколько еще Сноуден НЕ рассказал? И сколько секретов есть помимо тех что он знает. Да хотя бы список рекомендованных «эпилептических» кривых, можно ему доверять?
              • +7
                Настоящие параноики пользуются эпилептической криптографией!
                • +1
                  В смысле, шифруют всё и вся во время приступов…
                • +3
                  Настоящие параноики криптографией не пользуются. Они просто никому, кроме себя, тайн не доверяют.
                  • 0
                    Параноикам добрый совет, open source вам в руки, ничто не мешает для личных целей проявить немного фантазии и пере собрать модули шифрования изрядно посолив\поперчив\обхэшив и засушиф блоуфишем…

                    Нужно понимать, что конечные пользователи, не такие уж и умные, просто используют набор готовых утилит, для которых ваша фантазия, даже очень примитивная, окажется непреодолимой…
                    • +5
                      Я уже писал несколько раз в комментариях к подобным статьям на хабре, что тут open source не помощник. Ну прочитаете вы исходник, и что? Найти такую уязвимость в Dual_EC_DRBG программист не может, это может криптоаналитик. А хороших криптоаналитиков всего тысячи в мире, и я не буду удивлён, если большая часть из них прямо или косвенно работает на правительство США, а большая часть из оставшихся — на правительства своих стран.

                      Вот типичный пример, отлично иллюстрирующий мою мысль:
                      In order to keep a warning from being issued by the Valgrind analysis tool, a maintainer of the Debian distribution applied a patch to the Debian implementation of the OpenSSL suite, which inadvertently broke its random number generator in the process. The broken version was included in the Debian release of September 17, 2006 (version 0.9.8c-1). Any key generated with the broken random number generator, as well as data encrypted with such a key, was compromised. The error was reported by Debian on May 13, 2008.
                      • +4
                        open source здесь в помощь. Именно по причине
                        большая часть из них прямо или косвенно работает на правительство США, а большая часть из оставшихся — на правительства своих стран

                        если они будут совместно разрабатывать криптоПО, сама открытость друг перед другом не даст им возможности вставить закладку для «своих»
                        • +6
                          Вы путаете ПО и алгоритмы. Так закладки подобного рода в алгоритмы закладывают (или не закладки, а баги, которые потом используют кому надо). Алгоритмы тоже публичны, можете свободно читать, как, например, sha2 устроен. Сможете там багу или закладку найти? Я — точно нет, хотя считаю себя неплохим программистом.

                          Те, кто алгоритмы разрабатывают — они не программисты совсем, а скорее математики. Они не могут разрабатывать ПО, потому что не умеют. У них своя песочница, со своими конференциями и прочим, всё это довольно слабо пересекается с программированием. И про всякие допуски секретности не забывайте.

                          А вот проверить, что ПО правильно написано и реализует алгоритм правильно — вот это уже по силу разработчикам софта, баги типа дебиановских могут быть починены таким способом. Правда, чтобы найти такой баг, скорее всего нужен уже криптоаналитик.
                          • +2
                            Не знаю, может, все разработчики криптоалгоритмов — ни на что не способные идиоты (как тут кто-то предполагал выше), но вот вам история про то, как Лев Ландау читал статьи в научных журналах.

                            Он брал статью, читал абстракт и исходные положения, после чего сам строил математическую модель и проделывал все выкладки. Потом он сравнивал результат с результатом в конце статьи. Если результаты различались, статья объявлялась плохой.

                            Разумеется, «различались» они в широком смысле — то есть, с точностью до обозначений, констант, всяких неявных или явных предположений, до которых Дау просто не дочитал, также он не исключал собственной ошибки. Но в случае различий сравнение выкладок из статьи и собственных полностью раскрывало ситуацию.

                            По моему мнению (которое в данном случае невероятным образом совпадает с мнением Ландау), всем учёным желательно, а тем, кто занят теоретическими дисциплинами — так и вовсе обязательно работать именно таким образом: не читать статью, пролистывая выкладки, а выполнять их самому и сравнивать результаты. (Экспериментаторы не всегда могут так работать — всё-таки сложный эксперимент не всегда возможно досконально повторить, например, представьте себе проверку результатов LHC.)

                            Криптоаналитики, без сомнения, относятся к «теоретикам». Им не нужно особое оборудование для работы, только бумага, карандаш и персоальный компьютер. Если они будут работать так, как Ландау, то они безусловно либо случайно повторят ошибку в статье (что намекает на то, что про неё не знает и сам автор статьи), либо выявят её; иначе — они — они безмозглые ленивые кретины и их нужно выгнать «вон из профессии», такие не могут называться криптоаналитиками. Где проблема? Разве что в том, что нормальных криптоаналитиков нет?
                            • +1
                              Вообще, мне довольно сложно вам аргументированно что нибудь сказать, я не криптоаналитик, не математик и не физик.

                              Вы написали про доказательства верности выкладок, их непротиворечивость. Но ведь даже если выкладки верны — это не значит, что в них нету никаких уязвимостей. Например, история MD5:
                              разработали в 1991 году
                              теоретические уязвимости в 1993 году
                              первая практическая атака в 2005 году
                              практические атаки за приемлемое количество времени в 2006 году

                              У меня есть сомнения, что все учёные в мире были 10 лет слепы :) Подозреваю, что тут как с программами: показать и доказать, что правильно работает какой нибудь printf — это одно, а найти в нём багу — совсем другое.
                              • 0
                                607
                                Уже заколебали со своими «уязвимостями» MD5!

                                Эти уязвимости были или известны сразу после изобретения (то, что с изобретением более быстрых процессоров тупой перебор станет проще), или не так значительны — уязвимость «создать с нуля два столкнувшихся сообщения» — страсть как практически применимо, я (merlin-rterm @ Habrahabr) весь дрожу в ужасе.
                                Вот вам MD5 всего текста выше (в utf-8, в конце перевод строки, все переводы — \n): 11d80a290b6cc8ea9f042f14c3944bb8
                                Считайте это число подписью. Давайте, подделайте сообщение, хотя бы найдите коллизию, желательно, чтобы она была бы связным текстом на русском языке (я всё-таки опубликовал это на Хабре). Сколько вам времени понадобится? А это было самое прямое тупое использование MD5 для подписи. (Число вначале — длина сообщения без самого этого числа и перевода строки за ним.)

                                И я вовсе не про программу. Я про алгоритмы. Несколько раз построить одинаково неправильный сложный алгоритм — сомневаюсь.
                                • 0
                                  Вы примерно про это www.win.tue.nl/hashclash/Nostradamus/? Это не совсем подбор сообщения под хэш, но подбор паддингов нескольких сообщений, чтобы получить одинаковый хэш, получив возможность спуфинга.

                                  Атаки на MD5 типа туннелирования и chosen-prefix были придуманы в середине 2000х годов. При создании алгоритма было известно про тупой перебор и радужные таблицы, но они существенно менее эффективны, чем chosen-prefix коллизии.
                                  • 0
                                    Нет, я не про chosen prefix. chosen prefix меня не волнует никак. Я про preimage resistance. И это нереально.
                                • 0
                                  Проблема в том, что можно подписать одно, а использовать другое. Да, для «связного текста» это практически нереально, зато в бинарных файлах — запросто. Вот тут хороший пример, почему коллизии второго рода — это плохо.
                                • –2
                                  желательно, чтобы она была бы связным текстом на русском языке

                                  для одного из самых (если не самого) популярных применения хэширования — хранение паролей — требование связности лишнее, главное именно коллизию.
                                  • 0
                                    Не знаю, с чего вы взяли, что хранение паролей популярнее. Сравните, сколько раз функция хеширования вычисляется для подписи (напомню, каждый пакет VPN подписывается) и сколько — для хранения и проверки пароля.
                              • 0
                                Для атаки в лоб (поиск коллиззии 2 рода) на md5 необходимо примерно 2^64 операций (т.к. хэш 128 битный). В те годы это было заоблачным числом операций, да и сейчас это не мало. Зато сейчас практически любая слабость md5 позволяет атаке стать реальной (что и вышло на практике).

                                Хотя на вики написано, что для того же SHA1 есть теоретическая атака за 2^69 операций (причем еще в 2005 году). Странно, что до сих пор не нашли хотя бы одну коллизию…
                            • +1
                              Как я понял из изложения на stackoverflow (ссылка в конце статьи), там дыра не в самом алгоритме, а в том, что для реализации были выбраны не случайные точки на эллиптических кривых.
                              Это равносильно тому, что бы знать и публичный и приватный ключ в несимметричном шифровании.
                        • –3
                          > open source здесь в помощь
                          Существует огромное количество способов вставить закладку в открытый код так, что никто не догадается. Было уже много статей тут, где код скрывался последовательностью пробелов, неочевидными названиями, или даже якобы случайной опечаткой с одним «равно» вместо двух.
                          Ну, посмотрите вы в этот опенсурс — и что это вам даст?
                          Нет, тут нужна работа профессионального аналитика в этой области.
                          • +5
                            якобы случайной опечаткой с одним «равно» вместо двух.
                            Это, кстати, классический пример. Примечательно, что закладку почти сразу обнаружили. Будь она внедрена в продукт с закрытым кодом, могла бы продержаться долго, пока её не нашли сторонние хакеры.
                          • 0
                            Были ли реальные случаи обнаружения закладок в опенсурсе?
                            • 0
                              По крайней мере вот это очень известная история:

                              arstechnica.com/information-technology/2010/12/fbi-accused-of-planting-backdoor-in-openbsd-ipsec-stack/

                              • +1
                                А чем кончилась? Нашли в итоге бекдоры?
                              • +1
                                История то так и не подтвердилась. Никаких подтверждений этому никто, насколько я знаю, так и не нашел.
                                • +1
                                  Ну короче пока что одна известная мне закладка — в Debian OpenSSL по глупости мейнтейнеров Debian.
                      • +8
                        Я уже писал несколько раз в комментариях к подобным статьям на хабре, что тут open source не помощник.


                        Зато closed-source помощник тем, кто хочет заложить закладку.
                        • +1
                          Так, закладка на уровень выше. Берёте алгоритм, реализовываете на его основе кошерный open-source код, а там бац — и бэкдор. OpenSSL — отличная библиотека, развивается и поддерживается отличными разработчиками, используется чуть ли не на половине компьютеров мира, однако же не они написали про уязвимость алгоритма.

                          Использование столь сложных штук — это скорее вопрос веры, потому что для проверки собственными силами вам надо будет потратить несколько лет, и то не факт, что получится понять всю эту математику. Вот вы чуть ниже спрашиваете, используется ли Dual_EC_DRBG при генерации параметров в ECDSA в OpenSSL. Если используется не он, а другой — как вы проверите, что в нём нету подобных закладок на уровне самого алгоритма?
                          • +2
                            Это никак не противоречит моему комменту, на который Вы отвечаете. В closed-source можно не напрягаться с алгоритмическими закладкам можно заложить и чисто программные. И никто не догадается.
                            • +1
                              На самом деле есть методы верификации ГПСЧ, которые могут сказать, что он сломан. Я сейчас детали не вспомню, читал давно, но изучаются статистический свойства сгенерированной последовательности. То есть в случае с закладкой в исходниках эти методы могут рассказать про закладку. А вот в случае из поста — вряд ли, на сколько я понимаю, там не были ухудшены статистические характеристики генератора.
                              • +1
                                Имеете ввиду DIEHARD? Так они не всё ловят.
                      • –3
                        Я и не предлагаю всем и каждому становиться православными криптоаналитиками, это и не нужно…
                        А вот поднасрать в открытый код шифровалки без потери работоспособности оной программист таки сможет.
                        Хоть тупо в коде свой ГПСДП нарисовать и солить им уже зашифрованный поток данных :-)
                        Да это глупо, да специалисту не составит особого труда, но таких специалистов мало, стоят они дорого, а ещё придётся пропасти несколько сеансов вашей связи, так что можно спать относительно спокойно…
                        Или включить фантазию, устойчивое шифрование не такая уж сложная задача.
                        • +3
                          Вы предлагаете security through obscurity.
                    • –7
                      Вы хоть представляете сколько раз писался разными людьми доклад о стойкости этой крипографии? И исходники были и всё остальное. Только у людей не было мозгов чтоб реально проверить. И сейчас мозги такого уровня работают на правительства. Хоть усритесь с вашим опенсоусом. Он не поможет. В большинстве случаев он годится на горячую правку исходников… по манулу пятилетней давности… дабы пофиксить то, что делалось до этого уже стопятьсот раз. И не факт что кодер от АНБ, под предводительством пары математиков, опять закладку в него не сделает. Может пора успокоиться уже на эту тему и не давать этот дурацкий совет?
                      • +31
                        по манулу пятилетней давности
                        по манулу пятилетней давности
                        по манулу пятилетней давности
                        [манул]
      • 0
        По какому именно умолчанию? Уязвимый алгоритм в ключах ecdsa или ключи ecdsa вообще? Я уже осознанно использую ecdsa, вопрос — используется ли при этом уязвимый алгоритм?
        • 0
          Идея ecdsa не плоха, хотя потенциально может содержать фундаментальные уязвимости, тут я просто не берусь судить, но исключать бы не стал…
          В данном случае уязвимость именно в генерации ключей, в результате которой возникают поля значений которые можно окучивать или вычислять.
        • +1
          ecdsa тут вообще не причем. Закладка в алгоритме ГПСЧ который всего лишь как и ecdsa основан на эллиптической математике.
  • +2
    То есть, это никакой не random, если вы знаете в чём суть закладки.

    Не понимаю замысла автора… Если он не знает сути, то зачем изображает, что знает? Если знает, то зачем мутит ерунду что читатели должны знать?
    Но впечатление такое, что именно автор не знает, зато снобирует, будто знает.
    Даже если автор теперь прочтёт что сам наапдейтил в статье — мнения о его невежестве это не исправит.
    • 0
      снобирует

      сноудирует :)
    • +1
      смысл статьи рассказать о факте закладки, а не о её сути
      • +2
        Ну, суть ещё надобно понять :-)
  • +2
    Не, ну это понятно, что бекдор и все такое. А че теперь делать та?
    • +2
      Переходить на шифр Вернама. А криптоблокноты наполнять самодельными изотопными ГСЧ.
      До тех пор пока детекторы дыма есть в свободной продаже, как минимум.
    • 0
      • +1
        Минутку. Речь в статье про предсказуемый ГПСЧ, которые выдаёт при одном и том же зерне одну и ту же последовательность. Это важная харакетристика.
  • 0
    Шумиха сильно раздута.
    Во-первых, получается, что есть Dual EC_DRBG с закладкой (два числа вычисляются определенным образом с использованием «ключа» от АНБ) и Dual EC_DRBG без закладки.

    В устройствах RSA Data Protection используется первый вариант, «ключ» от их закладки знает АНБ. Позор им.

    Но это не значит, что в других местах тоже есть закладки!

    Более того, такой ключ даже не всегда можно подобрать (если правильно понял)!
    • 0
      Закладка вшита в сам алгоритм, независимо от реализации. В алгоритме прописаны константы, которые при неудачном стечении обстоятельств могут свести на нет всю его секьюрность
      • 0
        Алгоритм != константы. Константы можно заменить, главное выполнить [список условий для них]. Вы всегда можете использовать заранее посчитанные константы, приведённые в данной статье…

        К слову, это же относится к эллиптическим кривым в принципе. Есть стандартные кривые… Вроде кем-то доказана их безопасность…
        • 0
          В данном конкретном случае являются, т.к. именно в таком виде алгоритм был сертифицирован. Исследователи предложили каждый раз генерировать разные константы, но это уже другой алгоритм.
          • –1
            Так часть сертификации, или часть алгоритма? А на тему «сертификации в органах» — я вообще считаю, что сертификат сравни заявлению «спецслужбы с ними заодно»
        • 0
          Все несколько сложнее, константы там разные у каждого устройства. Иначе бы давно заметили. Доказать наличие закладки крайне сложно, не посмотрев код.

          Так что, советую использовать этот алгоритм только в Open Source реализации
          • 0
            Да хоть заглядись в код — отсутствие взаимосвязи констант доказать невозможно.
            Можно доказать только наличие взаимосвязи назвав то самое магическое e.
            • 0
              Ух, неохота сейчас качать код OpenSSL, но там я ожидаю увидеть что-то типа инициализации исходных параметров из /dev/random (генератор типа настоящих случайных чисел), независимо друг от друга.

              Раз уж на то пошло, такого магического e (ключа) может вообще не быть для двух случайных параметрах (для эллиптических кривых автор комментария на StackExcahnge сделал упрощение, считая группу точек циклической). Только вот выбрать такие два параметра уже сложнее.
              • +1
                так же как в случае обычного линейно-конгруэнтного генератора нельзя взять рандомный полином и радоваться жизни, так и тут нельзя взять рандомные точки на кривой, которые бы породили кольцо.
                в этом и есть главная засадница, почему используют магические константы…
                • –2
                  Тогда понятно, спасибо за объяснение.
                  • 0
                    www.untruth.org/~josh/school/phd/seminar/spring-2013-dual-ec-drbg/DualECDRBG.pdf

                    однако всё равно не могу найти алгоритма генерации понятным языком…
                • +1
                  какое такое кольцо на кривой?
                  • –3
                    Э. Вы в курсе, что такое ECC (ну, криптография на эллиптических кривых) и как она работает? Выясните и сами ответьте себе на вопрос.
                    • +1
                      Да вроде в курсе. Был когда-то. Забыл видимо.
                      И все-таки, мне интересно, почему нельзя взять рандомные точки на кривой; и какое кольцо они должны породить
                      • +2
                        Потому, что если взять просто две рандомных точки, через некоторое время генератор выродится в недлинный цикл.
                        Хорошо расписано у Кнута.
                        • 0
                          Мне кажется, функция перехода между состояниями достаточно похожа на случайную, поэтому в среднем будет цикл длины порядка sqrt(порядок g). И я сомневаюсь, что NIST/NSA/кто-либо другой в состоянии проверить, что длина цикла достаточно длинна (тем более, что при различных S могут получаться различные циклы и все их найти/проверить просто нереально).

                          Кроме того, никто не мешает оставить «заапрувленное» NIST'ом g (P на кривой) и выбрать случайно h (Q на кривой). Период последовательности зависит только от g, а выход при этом будет совсем другой.
                          • 0
                            Вот только если кривая Q зависит от P (а об этом речь и идёт) — из выхода случайного можно определить состояние — от этого выбор начальных и промежуточных точек как раз и не поможет
                            • 0
                              Q в любом случае зависит от P, Q=yP, как и P=xQ (потому что порядок группы простой). Определить состояние из выхода можно только дискретным логарифмом. Либо вычислить r=log(rQ, Q) и тогда rP=s', либо x=log(P, Q) и тогда xrQ = rP = s'.

                              Шанс выбрать случайно такие P и Q, что они окажутся «рядом» и дискретный логарифм легко возьмется, крайне маловероятен.
                              • 0
                                а где гарантии, что любая P и любая Q породят хорошую посоедовательность?
                                я вот что-то не могу нагуглить ограничения на них…
                                • +1
                                  Последовательность порождает только P, Q — просто преобразование на выходе.
                                  Гарантий нету, и никто их дать не может. Но вероятность того, что породится последовательность с коротким циклом — крайне мала.

                                  • +2
                                    можно ссылку на выкладки?
      • +1
        Вы не правы. Если константы выбираюсь наугад, то потом найти этот «ключ» будет очень не просто (задача дискретного логарифмирования), хотя теоретически возможно.
        Во второй статье эту часть комментария со StackExchange не перевели, к сожалению, но сама суть вкратце описана.
  • +1
    Мне бы хотелось верить, что вся эта история даст толчок для развития технологий в сфере информационной безопасности.
    Рынок усомнился, многие опасаются. Может, даже в этой ветке есть те, кто сумеет сделать информацию более качественно охраняемой и заработать.
  • 0
    А что АНБ то уже? Они уже заявили что разведка есть разведка, мол якобы если наша разведка лучше вашей то мы не виноваты…
    • +2
      тогда и сноуден не винован — если его разведка оказалась лучше их разведки — он же не виноват, да?
      • –1
        Ну он нарушил гос. тайну, скорее всего и условия договора. По сути дела его считают предателем и изменником т.к. вышли на свет данные о разведдеятельности США, и США потеряли доверие по всему миру. Он конечно виноват в этом смысле и только в нем, но он не виноват во многих других. Обидно за США, основы демократии оказывается.
  • +3
    Сноуден молодец. Тот толчек который он дал миру еще долго не забудется. Меньшее чего он достиг если у кого были какие то иллюзии теперь их нет. Мир станет осторожнее. Наверняка в ближайшем будующем появятся более безопасные средства шифрования. И это хорошо.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.