+++ /dev/null
-@node Bytecode
-@section Bytecode
-
-What is the most commonly used bytecode language in the world? Java
-(JVM Bytecode)? .NET (CLI)? Flash (AVM1/AVM2)? Nope. There’s a few that
-you use every day, simply by turning on your computer, or tablet, or
-even phone. You don’t even have to start an application or visit a
-webpage.
-
-@strong{ACPI}
-
-The most obvious is the large, gargantuan specification known as
-“ACPI”. The “Advanced Configuration and Power Interface” specification
-lives up to its name, with the most recent specification being a
-mammoth document that weighs in at almost 1000 pages. And yes,
-operating systems are expected to implement this. The entire thing. The
-bytecode part is hidden deep, but it’s seen in chapter 20, under “ACPI
-Machine Language”, describing a semi-register VM with all the usuals:
-Add, Subtract, Multiply, Divide, standard inequalities and equalities,
-but then throws in other fun things like ToHexString and Mid
-(substring). Look even further and you’ll see a full object model,
-system properties, as well as an asynchronous signal mechanism so that
-devices are notified about when those system properties change.
-
-Most devices, of course, have a requirement of nothing less than a full
-implementation of ACPI, so of course all this code is implemented in
-your kernel, running at early boot. It parallels the complexity of a
-full JavaScript environment with its type system and system bindings,
-with the program code supplied directly over the wire from any device
-you plug in. Because the specification is so complex, an OS-independent
-reference implementation was created by Intel, and this is the
-implementation that’s used in the Linux kernel, the BSDs (including Mac
-OS X), and the fun toy ReactOS, HaikuOS kernels. I don’t know if it’s
-used by Windows or not. Since the specification’s got Microsoft’s name
-on it, I assume their implementation was created long before ACPICA.
-
-@strong{Fonts}
-
-After that, want to have a graphical boot loader? Simply rendering an
-OpenType font (well, only OpenType fonts with CFF glyphs, but the
-complexities of the OpenType font format is a subject for another day)
-requires parsing the Type 2 Glyph Format, which indeed involves a
-custom bytecode format to establish glyphs. This one’s even more
-interesting: it’s a real stack-based interpreter, and it even has a
-“random” opcode to make random glyphs at runtime. I can’t imagine this
-ever be useful, but it’s there, and it’s implemented by FreeType, so I
-can only assume it’s used by some fonts from in the real world. This
-bytecode interpreter also contained at one time a stack overflow
-vulnerability which was what jailbroke the iPhone in JailbreakMe.com
-v2.0, with the OTF file being loaded by Apple’s custom PDF viewer.
-
-This glyph language is based on and is a stripped down version of
-PostScript. Actual PostScript involves a full turing-complete
-register/stack-based hybrid virtual machine based on Forth. The
-drawbacks of this system (looping forever, interpreting the entire
-script to draw a specific page because of complex state) were the major
-motivations for the PDF format -- while based on PostScript, it doesn’t
-have much shared document state, and doesn’t allow any arbitrary flow
-control operations. In this model, someone (even an automated program)
-could easily verify that a graphic was encapsulated, not doing
-different things depending on input, and that it terminated at some
-point.
-
-And, of course, since fonts are complicated, and OpenType is
-complicated, OpenType also includes all of TrueType, which includes a
-bytecode-based hinting model to ensure that your fonts look correct at
-all resolutions. I won’t ramble on about it, but here’s the FreeType
-implementation. I don’t know of anything interesting happening to this.
-Seems there was a CVE for it at one time.
-
-To get this article to display on screen, it’s very likely that
-thousands of these tiny little microprograms ran, once for each glyph
-shape in each font.
-
-@strong{Packet filtering}
-
-Further on, if you want to capture a network packet with tcpdump or
-libpcap (or one of its users like Wireshark), it’s being filtered
-through the Berkeley Packet Filter, a custom register-based bytecode.
-The performance impact of this at one time was too large for people
-debugging network issues, so a simple JIT compiler was put into the
-kernel, under an experimental sysctl flag.
-
-As a piece of historical interest, an earlier version of the BPF code
-was part of the code claimed to be infringing part of the SCO lawsuits
-(page 15), but was actually part of BSD4.3 code that was copied to the
-Linux kernel. The original BSD code was eventually replaced with the
-current architecture, known as the Linux Socket Filter, in Linux 2.2
-(which I can’t easily link to, as there’s no public repository of the
-Linux kernel code with pre-git history, as far as I know).
-
-@strong{What about it?}
-
-The popularity of bytecode as a general and flexible solution to
-problems is alluring, but it’s not without its complexities and faults,
-with such major security implications (an entire iPhone jailbreak from
-incorrect stack overflow checking!) and insane implementation
-requirements (so much that we only have one major implementation of
-ACPI used across all OSes that we can check).
-
-The four examples also bring out something interesting: the wildly
-different approaches that can be taken to a bytecode language. In the
-case of ACPI, it’s an interesting take on what I can only imagine is
-scope creep on an originally declarative table specification, bringing
-it to the mess today. The Type 1 Glyph and TrueType Hinting languages
-are basic stack-based interpreters, showing their PostScript heritage.
-And BPF is a register-based interpreter, which ends up with a
-relatively odd register-based language that can really only do simple
-operations.
-
-Note, though, that all of these implementations above have had security
-issues in their implementations, with numerous CVEs for each one,
-because bytecode interpreter implementations are hard to get right. So,
-to other hackers: do you know of any other low-level, esoteric custom
-bytecode specifications like these? And to spec writers: did you really
-need that flexibility?
-
-@url{http://blog.mecheye.net/2012/12/bytecode/}
+++ /dev/null
-@node Написание хороших писем
-@section Написание хороших писем
-
-Вы собираетесь пойти на работу в тренировочных штанах? Ваше
-распечатанное резюме будет содержать исправления от руки? Если вы на эти
-вопросы ответили отрицательно, то наверное вы также хотели бы писать
-профессиональные качественные email-ы. Окружение общества Интернет
-пользователей в этом плане очень строгое и стойкое. Здесь предоставлю
-небольшие рекомендации чтобы ваши письма были хотя бы на каком-то
-уровне.
-
-@table @asis
-
-@item Цитирование
-Общее правило: никогда не цитируйте полностью все
-письмо. Цитируйте только нужные части. Используйте inline метод
-цитирования (когда все письмо разбивается на несколько смысловых
-частей и ответ даётся под цитатой каждого). Урезайте цитируемое
-сообщение если это возможно.
-
-@item Тема
-Выбирайте нормальные что-то значащие темы сообщения. "Email",
-"Помогите", "Привет", или "Вопросы" далеко не самые лучшие темы
-сообщения. Если тема обсуждения в процессе общения изменилась --
-смените и тему письме. Если тем становится несколько -- создайте два
-письма с разными темами.
-
-@item Длина строки сообщения
-Она должна быть где-то около 72 символов.
-70, 74 или даже 76 -- ничего конечно же страшного, но большинство
-пользователей будут крайне недовольны если это будет больше. Email это
-не Web -- оно всегда было ориентировано, затачивалось под стандартные
-терминалы и принтеры, где происходит работы с простым текстом. Читать
-длинные строки и бегать глазами по экрану -- крайне неудобно, поэтому во
-вногих системах максимальная длина отображаемых символов равна 80
-символам.
-
-@item Подпись
-Делайте её маленькой и простой. Подписи длиной больше пяти строк лучше
-не делать. Подпись отделяется от письма на отдельной строке двойным
-дефисом и пробелом (@code{-- }). Эта последовательность уже больше
-тридцати или сорока лет используется во всех почтовых клиентах и
-серверах. Другие неприемлемы.
-
-@item Почтовые рассылки
-Отвечайте вашему собеседнику только в рассылку. Не надо отправлять копию
-письма ещё и лично ему (то есть использовать поле @emph{Cc}
-(carboon-copy)). Получатель может получить два одинаковых письма, что
-вряд ли ему понравится.
-
-@item Перенаправление писем (forwarding)
-Старайтесь давать краткое пояснение к тому что перенаправляете. Это
-также может сделать получателя недовольным как и глупая тема сообщения.
-
-@item HTML в письмах
-Не используйте его. Он был создан исключительно
-только для Web-а и никакого отношения к email не имеет ни технически,
-ни как-то ещё. Это лишнее увеличение в пустую сообщения и
-невозможность большинству почтовых клиентов отобразить его. Кроме
-того, HTML может нести массу больших опасностей в виде злоумышленного
-JavaScript, ActiveX, Flash, Java кода.
-@end table
-
-@strong{О top/bottom/inline-postingе}
-
-Есть три варианта ответов на цитируемое сообщение:
-
-@table @asis
-@item Top-posting
-Ответ идёт в самом начале письма, до цитаты. Пример:
-
-@verbatim
-Здесь расположен мой ответ на цитируемое письмо
-
-> бла бла бла яга
-> бла бла бла foo
-> бла бла бла foobar
-> бла бла бла bar
-@end verbatim
-
-@item Bottom-posting
-Ответ идёт в конце письма, после цитаты. Пример:
-
-@verbatim
-> бла бла бла яга
-> бла бла бла foo
-> бла бла бла foobar
-> бла бла бла bar
-
-Здесь расположен мой ответ на цитируемое письмо
-@end verbatim
-
-@item Inline-posting
-Ответ идёт после цитируемых логически разбитых частей сообщения. Пример:
-
-@verbatim
-
-> бла бла бла яга
-> бла бла бла foo
-Яга-баба
-
-> бла бла бла foobar
-> бла бла бла bar
-
-Бла бла бла
-@end verbatim
-@end table
-
-Применять нужно исключительно только последний вариант ответа, то есть
-inline-posting. Если логических/смысловых частей сообщения не больше
-одного, то, по сути, это конечно просто навсего bottom-posting. И таких
-сообщений большинство всегда встречается -- поэтому bottom-posting
-обычно не выделяют и не различают. Если же тем письма несколько -- стоит
-подумать не разбить ли его на два письма с соответствующими смыслами.
-
-Почему top-posting категорически должен избегаться и не использоваться?
-
-@itemize
-@item
-Он делает все сообщения непонятными, неразумными. Обычно ответ дают на
-то, что уже сказано. То есть человек читает о том, что кто-то что-то
-сказал -- а затем он читает ответ другого кого-то на это. Top-posting
-делает полную ахинею для людей которые обычно читают сверху вниз --
-сначала он читает ответ, а потом уже дальше осознает а на что же ему
-дали ответ.
-
-@item
-Почты может быть даже от одного человека очень много и постоянно
-помнить на что же кто-то должен прислать ответ -- нереально. А когда
-речь идёт о почтовых рассылках? Top-posting полностью убивает
-возможность понять о чем же идёт речь -- лишь только долго и
-кропотливо бегая по сообщениям.
-
-@item
-Top-posting делает невозможным нормальный удобный ответ на письмо.
-Можно вставить ответ на цитату самого этого top-postingа, однако если
-цитируемых сообщений (необходимых для вставки) было намного больше? То
-есть это выглядело бы примерно так:
-
-@verbatim
->часть 1 ответа на ответ на сообщение
-
-Ответ на часть 1 на ответ на сообщение
-
->часть 2 ответа на ответ на сообщение
->
->> ответ на сообщение
->>> сообщение
-
-Ответ на часть 2 на ответ на сообщение
-@end verbatim
-@end itemize
-
-@strong{Несколько небольших советов}
-
-@itemize
-@item
-Старайтесь не посылать большие вложения вместе с письмами. Используйте
-сторонние, более приспособленные для передачи больших объёмов
-информации, сервисы и пришлите ссылку на них, либо распространите файлы
-через BitTorrent, приложив torrent файл. Есть несколько причин, почему
-так лучше не делать.
-
- @itemize
- @item
- Если вложение не является текстом (7-битный ASCII текст, возможно с
- небольшим количеством 8-битных символов), то этот пункт можно
- пропустить. Иначе, все двоичные данные (русский текст тоже к ним
- относится) кодируются в Base64 кодировку, что приводит к увеличению
- его размера примерно на треть. Вместо трёх мегабайт, вы пошлёте
- четыре. Применяя более приспособленные для этого методы доставки
- файлов, такие как по HTTP или FTP протоколам -- вы это избежите.
- @item
- Далеко не всегда у всех будет под рукой Интернет с большой скоростью
- и малой ценой доступа. Как правило, почтовые клиенты настроены для
- того чтобы при подключении к серверу скачать всю новую почту, что
- может привести к нежелательным последствиям для удобства и денежного
- счета получателя. Передаваемая ссылка внутри письма может быть
- использована в любое удобное для пользователя время.
- @item
- Так как почтовые сервисы представляют из себя достаточно большие
- цепочки связанных SMTP-серверов, то каждое сообщение проходит
- довольно длинный путь. На каждом сервере, как правило, сохраняется
- проходящая через него почта. Это приводит к многократному
- дублированию больших объёмов данных. Крайне заметно это когда письма
- с вложениями отправляются в почтовые рассылки -- где рост
- продублированных данных идёт в геометрической прогрессии.
- @end itemize
-
-@item
-Сама по себе природа email -- крайне небезопасная. В том плане, что вся
-передаваемая информация почти всегда передаётся и сохраняется на
-большом количестве серверов в открытом, не зашифрованном, не
-защищённом виде. Никогда не передавайте важные данные без
-использования специального программного обеспечения, такого как
-PGP.
-@item
-При пересылке (forwarding) или ответе на сообщения, не меняйте порядок
-или сами слова. Только с разрешения самого автора.
-@item
-Следите за полем @emph{Cc} (carboon-copy). Не включайте туда лиц, когда
-общение уже перешло в разряд один-на-один.
-@item
-Учитывайте, что люди с которыми вы общаетесь могут находится на другом
-конце земного шара. Не ждите моментального ответа -- возможно
-получатель давно уже спит.
-@item
-Используйте смешанный регистр букв. ЗАГЛАВНЫЕ БУКВЫ ИСПОЛЬЗУЮТСЯ КОГДА
-ВЫ ХОТИТЕ ПОКАЗАТЬ ЧТО КРИЧИТЕ!
-@item
-Используйте символы для эмоционального выделения слов.
-@end itemize
-
-@copyright{} Сергей Матвеев
+++ /dev/null
-@node Статьи
-@unnumbered Технические статьи
-
-@itemize
-@item @url{https://www.schneier.com/crypto-gram/archives/1998/1215.html#contests, Security contests}
-@item @url{https://www.schneier.com/crypto-gram/archives/1999/0215.html#snakeoil, Cryptography snakeoil}
-@item @url{http://habrahabr.ru/company/ivi/blog/256365/, Реализуем безопасный VPN-протокол}
-@item @url{http://habrahabr.ru/company/ivi/blog/257431/, Реализуем ёще более безопасный VPN-протокол}
-@item @url{http://www.etegro.ru/articles/secure-disk-erasing, Удаление данных с жёстких дисков}
-@item @url{http://www.etegro.ru/articles/disk-encryption, Полнодисковое шифрование}
-@end itemize
-
-@menu
-* Безопасный SSH: Безопасный SSH.
-* Bytecode::
-* Написание хороших писем: Написание хороших писем.
-* Заголовки почтовых рассылок: Заголовки почтовых рассылок.
-* Приоритеты почтовых заголовков: Приоритеты почтовых заголовков.
-* Почтовые рассылки vs форумы: Почтовые рассылки vs форумы.
-@end menu
-
-@include articles/securing_ssh.texi
-@include articles/bytecode.texi
-@include articles/good_email.texi
-@include articles/maillist_headers.texi
-@include articles/mail_headers_priority.texi
-@include articles/maillist_vs_forum.texi
+++ /dev/null
-@node Приоритеты почтовых заголовков
-@section Приоритеты почтовых заголовков
-
-Правильно используйте функционал "Ответить",
-"Ответить всем"/"Групповой ответ", "Ответ в рассылку"!
-
-@strong{По простому для пользователей webmail}
-
-При получении письма из рассылки и возникновении желания ответить
-задумайтесь: всем ли интересно будет увидеть ваш ответ? То есть вы
-хотите ответить лично автору, либо всем в рассылке. Если лично автору,
-то жмите кнопку "Ответить". Если всем в рассылке, то жмите кнопку
-"Ответить" и измените адрес получателя (поле @emph{To}) на адрес рассылки.
-
-Webmail не имеет функционала ответа в рассылку, поэтому приходится
-совершать ручные действия. @strong{Не используйте} "Ответить
-всем"/"Групповой ответ", так как в поле @emph{To} окажется автор письма,
-уже являющийся членом рассылки, и адрес рассылки. Таким образом, автор
-получит два сдублированных письма. Если же и он произведёт групповой
-ответ, то двойные письма будут получать уже два человека и поле
-@emph{To} опять разрастётся. Человек, при этом отписавшийся от рассылки,
-всё равно будет получать почту, так как его адрес постоянно будет
-циркулировать в @emph{To}.
-
-@strong{Посложнее и коротко всем пользователям}
-
-Поведение почтовой программы при использовании трёх разных кнопок будет
-следующим:
-
-@itemize
-@item Ответить: @code{To=Mail-Reply-To|Reply-To|From}
-@item Групповой ответ:
-@code{(To=Mail-Followup-To) || (To=Mail-Reply-To|Reply-to|From, Cc=To + Cc - собственные адреса)}
-@item Ответить в рассылку: @code{To=Maillist, Cc=Mail-Followup-To - Maillist}
-@end itemize
-
-Через вертикальную черту указаны поля которые будут подставлены, в
-порядке их приоритета наличия в письме на которое совершается ответ.
-Некоторые почтовые клиенты могут не заполнять поле @emph{Cc}, используя
-вместо него @emph{To}.
-
-Таким образом, в рассылках групповой ответ (ответить всем) используется
-на практике только при общении также ещё и с человеком не подписанным на
-рассылку.
-
-@strong{Резюме}: используйте "Ответить" для ответа только автору и
-"Ответить в рассылку" для ответа, который все подписчики должны увидеть.
-
-@copyright{} Сергей Матвеев
+++ /dev/null
-@node Заголовки почтовых рассылок
-@section Заголовки почтовых рассылок
-
-@strong{Reply-To поле}
-
-Когда я пишу что-то в рассылку, то поле @strong{Reply-To}, которое
-создаётся почтовым клиентом содержит обычный адрес с которого я пишу.
-При публикации письма в рассылку это поле не меняется. БОльшая часть
-всех людей когда отвечают на мои письма из рассылки, похоже нажимают
-кнопку "Reply". Безусловно почтовый клиент в качестве получателя имеет
-адрес не рассылки, а мой личный. Ответа его другие подписчики не увидят.
-
-Это безусловно их право и выбор отправлять ответ лично мне, без
-возможности его обсуждения другими в дальнейшем. Лично я бы мог вручную
-прописывать в письмах в рассылку поле Reply-To в котором указать её
-адрес. До этого, когда у меня был Mailman и SmartList я их специально
-настраивал на принудительную подмену данного поля. Чтобы люди нажимая
-кнопку ответа писали в рассылку.
-
-Однако задумался -- а правильно ли это всё? Должна ли рассылка делать
-подмену Reply-To? Или это задача отправителя письма? Или вообще не надо?
-
-Нашёл такую статью: @url{http://www.unicom.com/pw/reply-to-harmful.html}
-которая считает подмену Reply-To крайне плохой штукой:
-
-@itemize
-@item
-Во-первых, она советует всегда следовать принципу минимальных
-изменений email-заголовков. Собственно это и так понятно и всегда
-хорошо. Если изменять, то чётко осознаваемый минимум;
-@item
-Во-вторых, она говорит что часто Reply-To подменяют чтобы люди при
-нажатии на кнопку ответа писали сразу же в рассылку (чего я и хотел).
-Но, здесь же сразу же напоминается и подчёркивается что уже несколько
-десятилетий даже в самых простых текстовых почтовых клиентах с
-командной строкой имеется команда "группового" ответа. И ведь верно. В
-большинстве известных мне клиентах есть команда ответа автору ("r") и
-отдельно команда группового ответа всем ("g"). Иногда это называется
-"Reply to all". Даже в графических клиентах это рядом располагающиеся
-кнопки. Вопрос ответа автору или всем доступно для обсуждения -- вопрос
-нажатия "r" или "g" (кнопочки чуть левее/правее).
-@item
-Учитывая предыдущий пункт, изменение поля Reply-To наоборот уничтожает
-возможность ответа автору! То есть обычный ответ и групповой приведут
-к одному и тому же результату -- а это ограничение того чего хотят
-подписчики рассылок.
-@item
-Более того, если Reply-To не совпадает с тем, что находится в
-@strong{From}, то желаемый адрес ответа пропадёт полностью. Что если
-отправитель не является как-таковым автором письма? Этого уже никто не
-узнает, так как Reply-To перетёрто.
-@end itemize
-
-В итоге, подмена Reply-To:
-
-@itemize
-@item нарушает принцип минимального изменения служебной метаинформации;
-@item абсолютно ничего полезного пользователям не даёт;
-@item ограничивает свободу выбора получателя ответа;
-@item ограничивает функционал почтового клиента;
-@item
-уничтожает важную информацию, утеря которой возможно приведёт к
-невозможности нахождения автора;
-@item
-нарушает принцип совершения наименьшего количества работы, так как
-ответ может стать более ёмкой процедурой;
-@item
-нарушает принцип наименьшего наносимого вреда, так как безвозвратно
-уничтожается служебная метаинформация.
-@end itemize
-
-@strong{Mail-Followup-To и Mail-Reply-To поля}
-
-Но, что же делать когда происходит нажатие кнопки группового ответа?
-Письмо фактически отправляется и автору и в рассылку. Не каждая почтовая
-рассылка умеет понимать такие ситуации и избегать отправки письма
-автору, если оно уже было отправлено сторонним отправителем. То есть,
-здесь безусловно может "помочь" только программное обеспечение рассылки.
-
-Как мне, автору письма в рассылке, сказать что ответ стоит отправлять в
-неё? Наверное можно Reply-To подправить и указать рассылку. А что если
-письмо адресовано не только в рассылку, но @strong{To} содержит ещё что-либо,
-или @strong{Cc} поле не пусто? Как сказать что ответ стоит, при нажатии кнопки
-группового ответа, отправлять всем, но допустим кроме меня?
-
-Если я всё-время буду присутствовать в To/Cc полях, то запросто могут
-приходить дубляжи сообщений. Даже если я отпишусь от рассылки, то из-за
-постоянного нажатия группового ответа я всё-равно буду получать
-сообщения обсуждения. Дубляжи можно "резать" на стороне локального
-почтового сервера (по идентичным @strong{Message-ID}), но это устранение
-последствий проблемы, а не корня её.
-
-Де-юре решения этой проблемы нет, но де-факто это использование поля
-@strong{Mail-Followup-To}. Поддержка данного поля должна присутствовать
-в почтовом клиенте. Его короткое и ясное объяснение есть здесь:
-@url{http://cr.yp.to/proto/replyto.html}.
-
-Поле содержит просто список адресатов кому следует отправить ответ. Если
-человек подписан на какую-либо рассылку из перечисленных адресов, то в
-Mail-Followup-To он свой собственный адрес не указывает. Если человек не
-подписан, то ответ само собой ему однозначно необходимо будет также
-направить и он себя включит в Mail-Followup-To.
-
-Почтовый клиент должен уметь понимать данное поле и создавать
-соответствующие поля To/Cc при ответе. Соответственно и при ответе в
-рассылку почтовый клиент может корректно заполнить данное поле. Например
-Mutt-у можно сказать что данный или данный адрес является рассылкой и он
-может автоматически генерировать Mail-Followup-To поле. Также Mutt-у
-можно сказать подписан ли автор на рассылку или нет -- что сыграет роль
-на его включение в поле.
-
-Кроме решения проблемы с групповыми ответами и дубляжом писем, данное
-поле позволит "увести" обсуждение за пределы какой-либо рассылки.
-Безусловно это поле можно и редактировать и просматривать руками, без
-поддержки его в клиенте. Кстати состояние его поддержки в различных
-клиентах имеется здесь: @url{http://www.leptonite.org/mft/software.html}.
-
-Кроме того, для "симметричности" ввели ещё одно поле: @strong{Mail-Reply-To}.
-Оно содержит адрес отправителя. То есть автора. Его поддержка тоже
-должна иметься в почтовом клиенте. Его роль проста: если рассылка
-перезаписывает оригинальное Reply-To поле, то его хотя бы можно будет
-"отыскать" здесь. Mail-Reply-To = Reply-To. Почтовый клиент должен в
-первую очередь будет посмотреть на Mail-Reply-To, потом уже на Reply-To,
-ну а потом уже только на From, если ни одного из этих полей нет.
-
-Есть доводы против использования данных заголовков, однако лично мне их
-примеры несостоятельности показались слишком надуманными и в целом всё
-сводится к тому, что мол все эти RFC относящиеся к почте -- дерьмо и два
-вышеуказанных заголовка лишь костыли. Безусловно несколько десятилетий
-назад люди не предполагали насколько email будет использован и как. Но
-если перейти на IPv6 ещё реально, то сменить SMTP...
-
-@copyright{} Сергей Матвеев
+++ /dev/null
-@node Почтовые рассылки vs форумы
-@section Почтовые рассылки vs форумы
-
-Материал в основном взят с @url{http://www.altlinux.org/MailVsForum, wiki.altlinux.org}.
-
-Форум предполагает наличие постоянно доступа в Интернет, постоянный
-online. Более того, как правило, тяжеловесные броузеры с поддержкой
-JavaScript. Почтовые рассылки требуют только почту, в целом работающую
-прекрасно (ну с задержками) в offline режиме. Это не эквивалентные по
-доступности сервисы.
-
-Поиск по форумам и рассылкам возможен. Но возможности поиска в форумах
-ограничены его движком, тогда как почтовые рассылки с хранимыми
-локально архивами не ограничены ничем — вы можете легко использовать
-любой софт, а не тот который поставил админ. И опять же поиск и
-просмотр почтовых рассылок возможен без online доступа.
-
-Эффективность использования интерфейса форума, даже самого
-продуманного, будет заведомо ниже эффективности использования
-интерфейса почты, в силу более узкой специализации почтовых клиентов
-по сравнению с броузерами — особенно сильно проявляется при
-использовании специальным образом настроенных текстовых редакторов для
-написания ответов вместо текстовой формы броузера. Почти невозможно
-встретить форум которым бы можно было пользоваться без мышки, где бы
-были хорошие фильтры сообщений, удобный threading и хотя бы наличие
-хоть какого-то scoring (работа с весами сообщений/thread-ов).
-Форматирование в полноценном редакторе а не textarea броузера не
-требует пояснений насколько удобнее.
-
-У форумов почти всегда разные интерфейсы, нет никакой унификации.
-Каждый форум это, грубо говоря, каждый раз новая программа со своим
-интерфейсом и возможностями. У почтовых рассылок интерфейс всегда
-ровно один, настроенный максимально удобно под каждого конкретного
-пользователя им лично, как ему удобно.
+++ /dev/null
-@node Безопасный SSH
-@section Безопасный SSH
-
-Данная статья -- попытка дополнить уже существующую относительно грамотную
-@url{https://stribika.github.io/2015/01/04/secure-secure-shell.html, Secure Secure Shell }.
-Но только относительно грамотную: некоторые вещи не являются правдой
-и поэтому часть рекомендаций не годна.
-
-@strong{Несогласия}
-
-Сразу же приведу список того с чем не согласен, для тех кто знаком со
-статьёй или её сутью:
-
-@itemize
-@item Мало затронута тема аутентификации сервера
-@item
-DES -- сломан, но не 3DES. Если уровень безопасности в 112 бит
-достаточен, то его использование приемлемо (если закрыть глаза на
-низкую производительность)
-@item
-RC4/Arcfour имеет особенности из-за которых некоторые реализации
-действительно можно считать сломанными. При **правильном** использовании
-Arcfour обладает хорошей силой и производительностью. OpenSSH
-реализовал этот алгоритм правильно: отбрасывается первые 1536 байт его
-выхода, разные не связанные между собой ключи. При своей
-производительности в контексте OpenSSH можно рассматривать к
-применению
-@item
-С какой стати размер блока шифра должен быть хотя бы 128 бит? Это
-действительно позволяет реже перегенерировать ключи шифрования, но
-кроме этой особенности в этом размере нет ничего страшного. Кроме
-того, автор выкинул CAST, но оставил Blowfish, хотя у него размер
-блока тоже в 64 бит
-@item
-Конечно дело паранойи и недоверия, но даже скептики типа Брюса Шнайера
-не видят особый смысл использования 256 бит ключей против 128. В AES-е
-безопасность пусть и 126.5 бит, но IMHO даже этого достаточно
-@item
-Автор так не доверяет NIST-овским кривым, но к AES не имеет никакого
-предвзятого отношения. Для меня это странно
-@item
-Почему-то полностью исключены UMAC алгоритмы MAC. И почему размер
-подписи должен быть не менее 128 бит. Если алгоритм MAC использует
-nonce-ы (например счётчик) на входе, то нет смысла встраивать эту
-информацию в сам тэг и при достаточно частой смене ключей
-аутентификации безопасность коротких тэгов вне сомнений (а это
-существенная экономия трафика, ведь с каждым сообщением добавляется
-этот тэг). UMAC их позволяет делать и, как правило, значительно быстрее
-HMAC. Poly1305 это как-раз разновидность UMAC
-@end itemize
-
-@strong{Проблема}
-
-Собственно почему всё это пишется. Эдвард Сноуден раскрыл
-@url{https://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html, документы}
-в которых упоминается что у спецслужб есть возможность прослушивать SSH.
-Как они это делают:
-
-@itemize
-@item получают долгоживующие асимметричные ключи с серверов или у пользователей
-@item дешифруют слабую криптографию
-@end itemize
-
-Под слабой криптографией подразумевается и действительно устаревшая, в
-которой в ходе многих лет криптоанализа нашли уязвимости, и та к которой
-приложили руку эти самые спецслужбы. Сноуден продемонстрировал что
-лазейки в алгоритмах они для себя
-@url{https://projectbullrun.org/dual-ec/vulnerability.html, сделали},
-чем и пользуются.
-
-Криптография это не только чисто математическая и техническая область.
-Огромный вес имеет доверие, репутация, даже политика. В данной статье
-предлагается настроить SSH сервер и клиент так, чтобы исключить слабую
-недоверяемую криптографию.
-
-@strong{Аутентификация сервера}
-
-Первым делом после установки TCP соединения SSH необходимо убедиться что
-на другом конце тот самый сервер который мы и ожидаем увидеть. То бишь
-аутентифицировать его. К сожалению SSH не поддерживает алгоритмы
-одновременной аутентификации и обмена ключами, хотя существуют алгоритмы
-даже двустороннего аутентифицированного обмена ключами. Но это лишь
-вопрос деградации производительности и трафика. Существуют патчи
-добавляющие SRP (двусторонний аутентифицированный обмен ключами), но его
-нет в mainline версиях OpenSSH.
-
-SSH предоставляет следующие алгоритмы:
-
-@itemize
-@item @code{ecdsa-sha2-nistp256}
-@item @code{ecdsa-sha2-nistp256-cert-v01@@openssh.com}
-@item @code{ecdsa-sha2-nistp384}
-@item @code{ecdsa-sha2-nistp384-cert-v01@@openssh.com}
-@item @code{ecdsa-sha2-nistp521}
-@item @code{ecdsa-sha2-nistp521-cert-v01@@openssh.com}
-@item @code{ssh-dss}
-@item @code{ssh-dss-cert-v00@@openssh.com}
-@item @code{ssh-dss-cert-v01@@openssh.com}
-@item @code{ssh-ed25519}
-@item @code{ssh-ed25519-cert-v01@@openssh.com}
-@item @code{ssh-rsa}
-@item @code{ssh-rsa-cert-v00@@openssh.com}
-@item @code{ssh-rsa-cert-v01@@openssh.com}
-@end itemize
-
-Итого это либо: RSA, либо DSS (вариант DSA), ECDSA (DSA на основе
-эллиптических кривых), Ed25519. DSS/DSA отпадают, так как стандартом
-определены длины ключей только размеров в 1024 бит, а этого уже
-недостаточно. ECDSA варианты отпадают так как используют кривые
-созданные NIST-ом и в них уже найдены
-@url{http://safecurves.cr.yp.to/, уязвимости}.
-
-Ed25519 это вне всяких сомнений лучший вариант: алгоритм подписей на
-основе эллиптических кривых, создан Дэниелем Бернштайном (независим от
-госорганизаций, корпораций, великолепный математик, криптограф,
-программист, хакер), работает за константное время, очень быстрый код,
-256 бит размер ключей.
-
-RSA сам по себе хуже только тем что сложнее реализовать (хотя в OpenSSH
-с этим проблем нет) и он во много раз медленнее и размеры подписей с
-публичными ключами занимают в разы больше места. Плюс никто не
-гарантирует что RSA ключи на сервере/клиенте будут сгенерированы
-достаточной длины.
-
-Мои предпочтения:
-
-@verbatim
-HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,
- ssh-ed25519,
- ssh-rsa-cert-v01@openssh.com,
- ssh-rsa-cert-v00@openssh.com,
- ssh-rsa
-@end verbatim
-
-@strong{Обмен ключами}
-
-После того как мы убедились что на другом конце тот кто нам нужен, то
-дальше необходимо установить (обменяться) ключи которые будут
-использоваться для шифрования и аутентификации сообщений. Этот этап за
-всё время сессии SSH может быть выполнен лишь один раз, но от него может
-зависеть абсолютно вся безопасность, так как не важно какой силы у вас
-алгоритм симметричного шифрования если ключи утекут на этапе обмена.
-
-Для обмена ключами используется асимметричный алгоритм Диффи-Хеллмана:
-самый первый в мире, революционный, асимметричный алгоритм. OpenSSH
-предоставляет следующие варианты:
-
-@itemize
-@item @code{curve25519-sha256@@libssh.org}
-@item @code{diffie-hellman-group-exchange-sha1}
-@item @code{diffie-hellman-group-exchange-sha256}
-@item @code{diffie-hellman-group1-sha1}
-@item @code{diffie-hellman-group14-sha1}
-@item @code{ecdh-sha2-nistp256}
-@item @code{ecdh-sha2-nistp384}
-@item @code{ecdh-sha2-nistp521}
-@end itemize
-
-ECDH это Диффи-Хеллман на эллиптических кривых, значительно более
-быстрый, но опять же использует NIST-овские кривые. Исключается.
-@code{diffie-hellman-group1-sha1} тоже исключается так как размер модуля
-группы DH 1024 бита. @code{diffie-hellman-group-exchange-} позволяет
-варьировать размеры группы от мала до велика: конкретные значения
-необходимо настроить (убрать маленькие) на сервере. Ну и SHA1 лучше
-перестать использовать совсем.
-
-Curve25519 схож с Ed25519. Обладает всеми теми же свойствами. Очень
-быстрый (вроде даже самый быстрый среди на практике используемых
-безопасных алгоритмов DH на основе эллиптических кривых), простой в
-коде, 256 бит размер ключей. Вне всякой конкуренции: он лучший.
-
-К сожалению многие серверы не поддерживают ни curve25519, ни даже все
-остальные DH.
-
-Мои предпочтения:
-
-@verbatim
-KexAlgorithms curve25519-sha256@libssh.org,
- diffie-hellman-group-exchange-sha256,
- diffie-hellman-group-exchange-sha1,
- diffie-hellman-group14-sha1
-@end verbatim
-
-@strong{Шифрование}
-
-После того как ключи установлены, то можно уже начинать и само
-шифрование -- то самое что гарантирует нам конфиденциальность. В отличии
-от этапа аутентификации и обмена ключами: производительность в данном
-контексте уже играет очень существенную роль. Одно дело получить на
-одном ядре процессора возможность передавать данные со скоростью
-гигабит, а другое дело еле-еле вытягивать несколько десятков мегабит.
-
-@itemize
-@item @code{3des-cbc}
-@item @code{aes128-cbc}
-@item @code{aes128-ctr}
-@item @code{aes128-gcm@@openssh.com}
-@item @code{aes192-cbc}
-@item @code{aes192-ctr}
-@item @code{aes256-cbc}
-@item @code{aes256-ctr}
-@item @code{aes256-gcm@@openssh.com}
-@item @code{arcfour}
-@item @code{arcfour128}
-@item @code{arcfour256}
-@item @code{blowfish-cbc}
-@item @code{cast128-cbc}
-@item @code{chacha20-poly1305@@openssh.com}
-@item @code{rijndael-cbc@@lysator.liu.se}
-@end itemize
-
-3DES: усиленная версия DES алгоритма, обладающая 112 бит силой. В
-принципе использовать можно если такой силы достаточно, однако не
-рекомендуется из-за безумно медленной скоростью работы. Ну и среди всех
-остальных алгоритмов эти 112 бит -- наименьшая безопасность.
-
-Arcfour (также известный как RC4): потоковый шифр, очень быстрый
-относительно многих других. Имеет много особенностей и проблем с
-правильным использованием. Настолько много что его рекомендуют никогда
-не применять. Говорить что он совсем сломан и не юзабелен я бы не стал,
-но рекомендовать его тоже не стоит.
-
-CAST128 -- предшественник одного из финалистов конкурса AES, одобрен к
-использованию на государственном уровне в Канаде (читай: канадский ГОСТ).
-Каких-то критичных недостатков вроде не имеет, но и производительностью
-или чем-то другим интересным не выделяется.
-
-Rijndael -- финалист конкурса AES. Честно говоря, не знаю разницы в
-OpenSSH между этим Rijndael и AES. Возможно это оригинальная не
-ослабленная AES версия алгоритма.
-
-AES -- известный, популярный, полно где применяющийся алгоритм. За
-десятки лет имеет много криптоанализов. Может смущать что это
-ослабленная версия Rijndael (для повышения производительности, как
-официально заявляется), но многие годы анализов не выявили атак которые
-бы призвали его в негодность. Брюс Шнайер, Дэниель Бернштайн доверяют
-этому алгоритму. Хотя у него и имеются проблемы в реализациях: ключи
-например могут утекать через кэш процессоров современных. Да и сама
-реализация не такая уж простая в коде. В любом случае это очень неплохой
-компромисс между безопаснотью/сложностью и производительностью.
-
-Blowfish -- старый, хорошо известный (проанализированный) алгоритм
-созданный Брюсом Шнайером. Независимость от госструктур, хорошо
-проанализированный, имеющий неплохую производительность. Если есть
-недоверие к AES, то я бы рекомендовал.
-
-В AES есть три варианта: CBC, CTR, GCM. Это разные режимы шифрования. Не
-вдаваясь в подробности: в SSH выявлена уязвимость при которой можно
-получить до 32 бит открытого текста (дешифровать его то бишь).
-Необходимо либо обновить SSH-сервер, либо как контрмера простая: не
-использовать CBC режим. Сам CBC не имеет уязвимостей: это лишь в
-контексте SSH у него есть такой недостаток. Даже если SSH у вас свежий,
-то CBC всё-равно не рекомендовал бы: для его сообщений требуется
-дополнение (увеличение трафика) и его вычисления нельзя распараллелить.
-CTR (режим счётчика): можно распаралаллелить вычисления, не требует
-дополнения. GCM: относительно недавно введённый режим
-аутентифицированного шифрования (поэтому не во всех SSH-релизациях
-встретится) -- то есть одновременно сразу же при шифровании производится
-и вычисление аутентифицирующего тэга. Очень сильно подкупает то, что GCM
-в современных x86-процессорах имеет аппаратное ускорение. Даже без него
-не требует как и CTR дополнения, может быть распараллелен.
-
-ChaCha20-Poly1305: опять же вне конкуренции это лучший вариант. ChaCha20
-алгоритм потокового шифра (более быстрый вариант Salsa20) совмещённый с
-Poly1305 алгоритмом аутентификации. Созданы опять же Дэниелем
-Бернштейном, не имеет хоть сколько-то серьёзных выявленных проблем в
-безопасности, очень просты в реализации (менее 100 строк кода на C),
-имеют фантастическую производительность: они быстрее аппаратно
-ускоренного AES-GCM. То есть более надёжный, более безопасный, более
-быстрый чем аппаратно ускоренный AES алгоритм аутентифицированного
-шифрования.
-
-Вопрос размера ключа шифрования скорее религиозный, вопрос доверия. В
-принципе 128 бит достаточно. AES-128 имеет 126.5 порог безопасности. По
-мне так и этого достаточно. 256 бит лично я бы выбрал, если бы не сильно
-деградировала производительность. Кстати, ChaCha20 имеет 256 бит ключ и
-она даже при этом быстрее AES-128.
-
-Мои предпочтения:
-
-@verbatim
-Ciphers chacha20-poly1305@openssh.com,
- aes128-gcm@openssh.com,
- aes128-ctr,
- blowfish-cbc
-@end verbatim
-
-@strong{Аутентификация сообщений}
-
-Зашифрованные сообщения могут быть при передаче изменены. Изменение
-шифрованного текста может приводить к осознанному изменению открытого
-текста после дешифрации. Передавать неаутентифицированные сообщения
-нельзя никогда. Кроме того необходима проверка их целостности. OpenSSH
-предоставляет следующие алгоритмы:
-
-@itemize
-@item @code{hmac-sha1}
-@item @code{hmac-sha1-96}
-@item @code{hmac-sha2-256}
-@item @code{hmac-sha2-512}
-@item @code{hmac-md5}
-@item @code{hmac-md5-96}
-@item @code{hmac-ripemd160}
-@item @code{hmac-ripemd160@@openssh.com}
-@item @code{umac-64@@openssh.com}
-@item @code{umac-128@@openssh.com}
-@item @code{hmac-sha1-etm@@openssh.com}
-@item @code{hmac-sha1-96-etm@@openssh.com}
-@item @code{hmac-sha2-256-etm@@openssh.com}
-@item @code{hmac-sha2-512-etm@@openssh.com}
-@item @code{hmac-md5-etm@@openssh.com}
-@item @code{hmac-md5-96-etm@@openssh.com}
-@item @code{hmac-ripemd160-etm@@openssh.com}
-@item @code{umac-64-etm@@openssh.com}
-@item @code{umac-128-etm@@openssh.com}
-@end itemize
-
-Тут у SSH выявляется критически важный недостаток первоначальных
-реализаций. Подписать и зашифровать сообщение можно в разных порядках:
-
-@itemize
-@item зашифровать, потом добавить подпись зашифрованного сообщения
-@item добавить подпись открытого сообщения, потом зашифровать всё это
-@item зашифровать, потом добавить подпись открытого сообщения
-@end itemize
-
-Первый вариант делает IPsec, второй TLS, третий SSH. Вариант SSH
-категорически нельзя применять. Вариант TLS может быть атакован, что и
-сделали в BEAST атаке. Вариант IPsec (Encrypt-then-MAC) всегда правилен
-и только так и должен применяться. Половину доступных алгоритмов в
-OpenSSH имеют приписку etm (Encrypt-then-MAC) и только они и должны
-всегда использоваться. К сожалению многие SSH серверы всё ещё не
-обновляются и не поддерживают их.
-
-Как я уже говорил в начале, короткие 64-бит тэги вполне приемлемы если
-правильно реализованы. Они быстрее вычисляются и меньше трафика едят.
-
-UMAC появился позже HMAC-ов, но пока не имеет недостатков в безопасноти.
-Зато имеет преимущество в виде высокой скорости работы зачастую.
-
-Остальные HMAC отличаются только используемой хэш-функцией. MD5 реально
-сломан, но в контексте HMAC он вполне себе годный к использованию. SHA1
-уже не рекомендуется, но он тоже годен. Если очень важна
-производительность, то конечно HMAC-MD5 будет быстрее всех. Но я бы как
-и автор статьи рекомендовал бы не поддерживать криптографию от которой
-реально надо бы избавляться. Завтра не исключено что найдут ещё более
-серьёзную уязвимость в MD5/SHA1 и HMAC-MD5/SHA1 которая их сразу же
-приведёт в негодность, а трафик уже был перехвачен и записан нехорошими
-людьми.
-
-RIPEMD-160 создан в академических кругах, независимо от госструктур. Не
-имеет применимых криптоатак. Имеет 160 бит хэш, более короткий чем у
-SHA2, а значит экономящий трафик.
-
-SHA2 уже тоже не советуется к применению. Обладает пока достаточной
-криптографической силой, но он гораздо более медленный чем все
-остальные.
-
-Подчеркну что отдельный этап аутентификации сообщений, MAC, не
-применяется если мы уже использовали аутентифицированный режим
-шифрования. То есть GCM режим это уже применение аутентификации, так же
-как и Poly1305 это тоже чисто режим аутентификации (кстати это
-разновидность UMAC). Поэтому данная настройка не играет никакой роли для
-подобных шифров.
-
-Мои предпочтения (вынужден добавлять и не @code{-etm} версии из-за кучи
-не обновлённых серверов):
-
-@verbatim
-MACs umac-64-etm@openssh.com,
- umac-128-etm@openssh.com,
- hmac-ripemd160-etm@openssh.com,
- hmac-sha2-256-etm@openssh.com,
- hmac-sha2-512-etm@openssh.com,
- umac-64@openssh.com,
- umac-128@openssh.com,
- hmac-ripemd160,
- hmac-sha2-256,
- hmac-sha2-512
-@end verbatim
-
-@strong{Общие рекомендации}
-
-@itemize
-@item Используйте сильную парольную фразу для ваших клиентских ключей
-@item Шифруйте диск где находятся ключи сервера
-@item
-Используйте только свободного программное обеспечение, проверенные
-временем и криптоанализами алгоритмы шифрования и, что важнее, их
-реализацию
-@item
-Следите за security обновлениями
-@item
-Не добавляйте то чего можно не добавлять. Каждая лишняя строчка кода
-это лишний повод появиться уязвимости. Не обновляйтесь ради обновления
-@end itemize
-
-@copyright{} Сергей Матвеев
@item доступен по @emph{IPv4}, @emph{IPv6} адресам
@item доступен как скрытый сервис сети Tor:
@url{http://vabu56j2ep2rwv3b.onion/}
-@item не использует JavaScript и прочие избыточные технологии из
- коммерциализованного мира
@item DNS-адреса подписаны @url{https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions, DNSsec}
@item имеются @url{https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities, DANE}
записи для TLS сертификатов
@item Криптопати @ref{Правила проведения cryptoparty, не признаёт}
агрессию и оскорбления.
@item Не рассылать offtopic и спам сообщения.
-@item @ref{Написание хороших писем, Не использовать} top-posting при ответе!
+@item Не использовать top-posting при ответе.
@item Цитировать только необходимое или вырезать цитаты совсем.
@item Формат сообщений -- только простой текст, никакого HTML.
@item Не прикреплять большие вложения к отправляемым письмам.
--- /dev/null
+@node FAQ
+@unnumbered Часто задаваемые вопросы
+
+@table @asis
+
+@item @anchor{warez} Как бесплатно качать софт, музыку и фильмы?
+
+Если автор хочет получать материальную выгоду от своего творчества, то
+это его право требовать денежную компенсацию при распространении. Если
+вас не устраивает цена: договаривайтесь с ним, ищите компромиссные
+варианты, которые бы удовлетворили обе стороны. В противном случае,
+скорее всего, распространение такого рода будет считаться воровством.
+Шифропанки хоть и решают технические задачи, но прежде всего люди должны
+оставаться людьми, с соответствующими этическими нормами.
+
+@item @anchor{censorship} Как мне обойти цензуру?
+
+Если кто-то поставил ограничения, то возможно неспроста, а ваше желание
+их обойти это нарушение закона? Если мы дадим ответ, то значит поможем
+именно вам, значит признаем косвенно что вы более правы чем цензор.
+Политические игры и решения -- не наш удел.
+
+Однако намекнём что есть такое понятие как цензуроустойчивые (censorship
+resistant) сети и технологии, такие как @url{https://gnunet.org/,
+GNUnet}, @url{https://freenetproject.org/, Freenet} и другие.
+
+@item @anchor{cryptoanarchy} Как мне, используя технологии шифропанков, достичь криптоанархии?
+
+Шифропанки заинтересованы в решении исключительно технических задач.
+Анархия -- это политические и социальные вопросы.
+
+@item @anchor{software} Какие критерии выбора программ для защиты приватности имеются?
+
+ @itemize
+
+ @item Убедиться что вам предоставляют полноценную программу,
+ @url{https://www.gnu.org/philosophy/who-does-that-server-really-serve.ru.html, а не услугу}
+ требующую участие сторонних лиц. Используя терминологию маркетинга:
+ остерегайтесь облачных сервисов. Их использование возможно только
+ если перед отправкой данных обеспечивается надёжная
+ криптографическая защита, но даже в этом случае вы сможете
+ гарантировать только конфиденциальность данных, но не анонимность.
+
+ @item Программа @strong{должна} быть
+ @url{https://www.gnu.org/philosophy/free-sw.ru.html, свободным}
+ программным обеспечением. Проприетарное ПО не даёт возможность
+ контролировать ваш же собственный компьютер. Без контроля не может
+ быть речи о безопасности, следовательно и о приватности.
+
+ @item Остерегайтесь любой криптографии реализованной и исполняемой
+ внутри Web-броузера. Web-технологии являются неимоверно
+ переусложнёнными и никто не в состоянии адекватно проанализировать и
+ исправить недостатки связанные с безопасностью. Web создавался как
+ распределённая система документов, а не как платформа запуска
+ приложений. В вашей приватности практически никто в Web-мире не
+ заинтересован.
+
+ @item Не поддавайтесь на
+ @url{https://www.gnu.org/philosophy/javascript-trap.ru.html, западню}
+ связанную с JavaScript: технически код может и исполняется внутри
+ вашего броузера, но, на данный момент, Web-броузеры не дают
+ возможность контролировать код который загружается для исполнения.
+
+ @item Оцените серьёзность программы: не является ли она, так
+ называемым, marketing bullshit,
+ @url{https://www.schneier.com/crypto-gram/archives/1999/0215.html#snakeoil,
+ шарлатанской криптографией}. Сильно должны настораживать следующие
+ фразы:
+
+ @itemize
+ @item собственные, уникальные, революционные, проприетарные
+ алгоритмы;
+ @item новейшая математика;
+ @item невзламываемый, миллион бит вместо 128, "сильный как
+ One-Time-Pad";
+ @item быстрый: подходит для сервера и для обычного ПК.
+ @end itemize
+
+ @item Наличие криптографических конкурсов это
+ @url{https://www.schneier.com/crypto-gram/archives/1998/1215.html#contests,
+ очень плохой знак}. Конкурсы практически никогда не работают:
+
+ @itemize
+ @item у них нечестные условия: предлагают проверять танк
+ разрешая стрелять только из автомата -- не дают возможность
+ использовать весь арсенал известных атак;
+ @item цена выигрыша конкурса банально может не окупить затраты
+ на анализ;
+ @item порог вхождения для получения конкретного результата, а не
+ математического доказательства возможности его получения,
+ довольно высок -- вопрос экономической целесообразности участия.
+ @end itemize
+
+ @end itemize
+
+@item @anchor{windows} Как мне добиться приватности в Microsoft Windows или Apple OS X?
+
+В общем случае -- никак. Вы не знаете что делают эти операционные
+системы с данными, не знаете где и какие они имеют лазейки, не можете
+гарантировать качественную работу генератора псевдослучайных чисел. В
+некоторых случаях, например когда компьютер не подключён к сетям
+передачи данных (airgap mode), риски не так велики. Прежде чем
+затрачивать силы на то чтобы повысить безопасность работы в этих
+системах стоит оценить затраты на переход на свободное ПО -- как
+правило, они будут гораздо ниже.
+
+Что вам дороже: безопасность и приватность или удобство? Как правило,
+достичь одновременно обе эти цели технически невозможно. Безопасные
+решения требуют ответственности пользователей, более высокий порог
+вхождения. Или вы принимаете решения о вашей же собственной безопасности
+и приватности -- или их примут за вас, вряд ли в вашу пользу.
+
+@item @anchor{whytrust} Почему я должен доверять советам и ответам автора этого ресурса?
+
+Не должны. Мы такие же люди как и маркетологи, пиарщики и психологи. Наш
+перевес в том, что мы увлекаемся и интересуемся криптографией и пытаемся
+давать объективные технические оценки, а не полагаться на красивые
+презентации. Наш искренний совет: доверяйте криптографам.
+
+@item @anchor{encryption} Чем лучше зашифровать файл перед отправкой?
+
+@url{https://gnupg.org/, GnuPG}.
+
+@item @anchor{email} Чем шифровать электронную почту?
+
+GnuPG.
+
+@item @anchor{signatures} Чем осуществлять аутентификацию ПО или документов при скачивании?
+
+GnuPG.
+
+@item @anchor{diskencryption} Чем полностью зашифровать диск?
+
+Большинство операционных систем предлагают вполне сносные решения из
+коробки:
+@url{https://gitlab.com/cryptsetup/cryptsetup/blob/master/README.md,
+LUKS} под GNU/Linux,
+@url{http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/softraid.4?query=softraid&sec=4&arch=i386,
+softraid} под OpenBSD,
+@url{https://www.freebsd.org/doc/en/books/handbook/disks-encrypting.html,
+GELI} под FreeBSD. Важно использовать @strong{XTS} режим шифрования во
+всех перечисленных системах.
+
+Операционные системы Microsoft Windows и Apple OS X не имеют средств
+шифрования из коробки которым можно было бы доверять.
+
+@item @anchor{chats} Чем обеспечить приватность real-time переписки?
+
+Instant messaging клиентами поддерживающими
+@url{https://otr.cypherpunks.ca/, Off-the-Record} протокол (или его
+производными типа
+@url{https://www.whispersystems.org/blog/advanced-ratcheting/, TextSecure}).
+
+@item @anchor{anonymization} Как анонимизироваться в Web и вообще в Интернете?
+
+В общем случае ответа на этот вопрос нельзя дать. Очень много зависит не
+только от вас, но и от тех кто предоставляет сайт. Векторов для вашей
+деанонимизации настолько много, что быстро оценить все риски и возможные
+утечки информации -- очень сложно.
+
+Проще всего использовать сети/программы изначально задумывающиеся как
+уважающие приватность: GNUnet, Freenet, @url{https://geti2p.net/en/,
+I2P}, @url{https://en.wikipedia.org/wiki/RetroShare, Retroshare}.
+
+И не забывать оценивать риски! Обеспечить анонимность при real-time
+коммуникациях (пытающихся гарантировать минимальные задержки при
+передаче данных) -- практически невозможно. Так называемые
+store-and-forward решения (GNUnet, Freenet, другие) гораздо надёжнее, но
+Web в них работать не сможет.
+
+В крайнем случае можно посмотреть на @url{https://www.torproject.org/, Tor}.
+
+@item @anchor{slownet} Но сеть анонимизации XXX медленная!
+
+Во-первых, в отличии от шифрования (то что обеспечивает приватность
+передаваемых @strong{данных}), анонимизация требует использование
+большой группы участников (так называемый anonymity set) -- так как
+анонимизация это обеспечение приватности @strong{метаданных}.
+
+Во-вторых, anonymity set создают @strong{только} энтузиасты, только
+добровольцы, только простые люди. Никакая корпорация не заинтересована в
+обеспечении вашей приватности. Это исключительно личная потребность.
+Поэтому ресурсы на создание anonymity set могут появится только за счёт
+кооперации людей.
+
+Пока вы не начнёте кооперировать, поднимать у себя программы делающие
+ваш компьютер участником anonymity set какой-либо сети -- она не будет
+работать, не будет существовать. Поэтому вопрос почему сеть XXX такая
+медленная адресован к обычным людям: почему мы не участвуете в
+предоставлении части ресурсов вашего компьютера для того чтобы сделать
+XXX быстрее, лучше и безопаснее? У преобладающего большинства
+компьютеров простаивают процессоры, имеется свободное место на жёстких
+дисках, многие имеют высокоскоростные выделенные Интернет-каналы.
+
+@item @anchor{advices} Общие советы по использованию сетевых ресурсов?
+
+ @itemize
+
+ @item Избегайте слежки! Никто не заставляет вас использовать
+ google.com -- есть альтернативы типа @url{https://duckduckgo.com/,
+ DuckDuckGo}, @url{https://ixquick.com/, Ixquick}. Никто не
+ заставляет вас создавать почту на gmail.com -- вы можете сами
+ поднять почтовый сервер, можете использовать помощь более опытных
+ знакомых, можете использовать сервисы типа
+ @url{https://help.riseup.net/, Riseup}, хотя и в этом случае вы не
+ можете получить технические гарантии приватности вашей почтовой
+ переписки. Никто не заставляет использовать только пару социальных
+ сетей -- есть возможность запустить свою собственную, независимую от
+ рекламы, корпораций или государств: @url{http://gnu.io/, GNU
+ social}, @url{https://diasporafoundation.org/, diaspora*}.
+
+ @item Не "сорите" данными! Включайте cookie в вашем броузере только
+ для нужных доменов и только когда это действительно требуется.
+ Отключите JavaScript по-умолчанию: в 99% случаев он не нужен для
+ путешествия по Web-у. Большинство ресурсов требующих его
+ использование в обязательном порядке -- априори не ставят задачи
+ уважить вашу приватность. Используйте анонимные средства оплаты,
+ (на данный момент это только "наличка"): нет надобности сообщать
+ ваше имя при покупке хлеба расплачиваясь банковской картой.
+
+ @item Блокируйте слежку (сбор вашей приватной информации)! Шифруйте
+ передаваемые данные (OpenPGP, TLS, OTR, XTS, и тому подобные).
+ Анонимизируйте метаданные.
+
+ @end itemize
+
+@item @anchor{telegram} Безопасен ли Telegram?
+
+Ни в коем случае. Подробнее можно прочитать
+@url{http://unhandledexpression.com/2013/12/17/telegram-stand-back-we-know-maths/,
+тут} и
+@url{http://www.cryptofails.com/post/70546720222/telegrams-cryptanalysis-contest,
+тут}. Если коротко, то: в secret chat-ах в момент создания сессии между
+двумя пользователями используется протокол Диффи-Хельмана. Беда в том,
+что сообщения этого протокола не аутентифицируются данными/ключами
+пользователей. То есть, технически сервер Telegram спокойно может
+выступить промежуточным "собеседником" (читающим все сообщения) для
+каждого из участников и они не будут догадываться о том, что уже
+произошла MitM атака.
+
+@item @anchor{bitcoin} BitCoin это криптопалюта будущего?
+
+Нет. Для нас это просто как ещё один очередной банк. Вся власть по
+контролю за BitCoin сосредоточена в руках самых богатых (mining фермы,
+которых не много). В отличии от систем основанных на слепых подписях,
+транзакции от пользователя в BitCoin не анонимны. Создатель BitCoin с
+самого начала говорил что сеть может работать только пока 51%
+вычислительных мощностей не будет у злоумышленника: то есть всё
+опирается на вероятность, а не гарантированную детерминированную
+надёжность.
+
+@item @anchor{socialnets} Почему на сайте нет ссылок на группы в соцсетях по теме?
+
+Это не правильно давать дань внимания ресурсам которые абсолютно не
+уважают приватность пользователей, осуществляют цензуру, поступают
+неэтично, манипулируют мнением людей, используют их как продукт.
+
+@item @anchor{simplicity} Почему этот сайт выглядит как унылое говно, никакого Web 2.0?
+
+Мы заботимся о максимальной доступности, совместимости, большей
+вероятности и возможности донести информацию до любого пользователя. Web
+2.0, CSS, JavaScript и прочие модные отбросы коммерциализованного мира
+вредят людям с ограниченными возможностями, пользователям у которых нет
+броузеров с графическим интерфейсом, у кого нет современного компьютера,
+у кого дорогой трафик Интернета.
+
+@end table
+++ /dev/null
-@node FAQ Filecrypt
-@section Как зашифровать файл перед отправкой?
-
-Допустим, вам необходимо безопасно кому-то отправить файл. Интернет
-каналы априори небезопасны и поэтому вам потребуется зашифровать файл и
-аутентифицировать (подтвердить что он действительно отправлен вами и
-дошёл без искажений).
-
-Во-первых, вам заранее необходимо будет обменяться хоть какими-то
-данными по сторонним каналам связи. Если это общий пароль, используемый
-в качестве ключа, то им, если это асимметричная криптография на основе
-публичных ключей, то публичными ключами, если это заранее известные
-ответы на вопросы известные только вам, то значит иметь их. Без этих
-действий отправить безопасно файл вы не сможете.
-
-@strong{Архиваторы}
-
-Если вам надо будет послать файл один раз и надолго забыть про это
-действие, то возможно подойдёт вариант с использованием архиваторов
-поддерживающих шифрование. Однако помните что архиваторы могут иметь
-ограниченное количество поддерживаемых платформ.
-
-@table @asis
-
-@item ZIP формат
-Вряд ли можно рекомендовать, так как современные версии формата
-поддерживают не многие программы, а в старых криптографическая стойкость
-абсолютно неудовлетворительна.
-
-@item RAR
-Нельзя рекомендовать, так как RAR является программой с закрытым
-исходным кодом: вы не знаете что и как она делает.
-
-@item @url{http://www.7-zip.org/, 7-zip}
-Наименьшее из зол. Имеет грамотно реализованную сильную криптографию с
-ключом на основе пароля.
-
-@end table
-
-@strong{OpenSSL}
-
-Возможен вариант с шифрованием файла вручную, напрямую используя
-утилиты @emph{OpenSSL} или схожих библиотек. Не рекомендуемый вариант
-так как грамотно сделать шифрование файла это не тривиальная задача для
-большинства и малейшая ошибка чревата полной потерей безопасности.
-
-@strong{OpenPGP}
-
-Наилучший вариант. Рекомендуемая реализация OpenPGP стандарта это
-де-факто широкоиспользуемая программа @url{https://gnupg.org/, GnuPG}.
-Кроме шифрования файлов вы получаете ещё и возможность:
-
-@itemize
-@item подписывать файлы, ставя на них электронную цифровую подпись,
-которую нельзя подделать, что используют в десятках дистрибутивах
-различных операционных систем, гарантируя что программы попадают на ваш
-компьютер не в искажённом виде (их не подменили, например, встроив
-вирус);
-@item шифровать и подписывать электронную почту.
-@end itemize
+++ /dev/null
-@node FAQ
-@unnumbered Часто задаваемые вопросы
-
-@menu
-* Безопасен ли Telegram?: FAQ Telegram.
-* Какой messenger выбрать?: FAQ Messenger.
-* Как зашифровать файл перед отправкой?: FAQ Filecrypt.
-@end menu
-
-@include faq/telegram.texi
-@include faq/messenger.texi
-@include faq/filecrypt.texi
+++ /dev/null
-@node FAQ Messenger
-@section Какой messenger выбрать?
-
-Мы рассматриваем только вопрос криптографической безопасности. Удобство
-это всегда дело субъективное: @strong{не бывает} инструментов удобных
-одновременно и профессионалам и новичкам. Поэтому важно выбрать
-открытый и свободный @strong{протокол}: к нему уже может быть много
-различных клиентов (и серверов) которые смогут удовлетворить вопросы
-удобства самых разных пользователей.
-
-Самый широкоподдерживаемый различными клиентами протокол это
-@url{https://otr.cypherpunks.ca/, Off-the-record} (OTR). Он может
-работать поверх любого транспортного протокола способного передавать
-английский текст (ASCII). Его можно рекомендовать: он существует уже
-более десяти лет, хорошо проанализирован и имеет хорошую безопасность.
-
-Также можно рекомендовать его производные версии:
-@url{https://www.whispersystems.org/blog/advanced-ratcheting/, TextSecure}
-и @url{https://github.com/trevp/axolotl/wiki, Axolotl}.
-
-Использовать OpenPGP систему для real-time общения можно, лучше чем
-ничего, но не рекомендуется:
-
-@itemize
-
-@item Компрометация OpenPGP ключей фатальна: потеряв их, сделав
-доступными злоумышленнику (например он установит keylogger и узнает
-парольную фразу от приватных ключей), все ваши отправленные сообщения
-можно будет дешифровать. OTR и производные от него протоколы используют
-протокол Диффи-Хельмана для создания сессионных ключей, нигде не
-сохраняющихся на жёстких дисках, при каждом сеансе связи --
-компрометация долгоживущих OTR ключей не сможет обеспечить дешифрование
-сообщений. То есть, OTR обладает свойством "совершенной прямой
-секретности" (perfect forward secrecy).
-
-@item Подписи OpenPGP дают гарантию что они сделаны именно автором и не
-могут быть подделаны. OTR имеет свойство "правдоподобного отрицания"
-(plausible deniability): третья сторона, сторонний наблюдатель, не может
-доказать ваше авторство над добавляемыми аутентификационными данными к
-пересылаемым сообщениям. Только вы сможете однократно проверить
-аутентичность приходящих данных. Более того, режим шифрования сообщений
-выбран такой, что он позволяет проводить модификацию данных и третья
-сторона не может доказать что увиденные ею сообщения были получены без
-искажений.
-
-@item OpenPGP требует заранее установить доверие между собеседниками. Вы
-не можете безопасно общаться друг с другом пока не убедитесь что
-публичный ключ противоположной стороны действительно принадлежит нужному
-человеку. OTR же предлагает использование протокола
-@url{https://en.wikipedia.org/wiki/Socialist_millionaire, SMP} --
-аутентификации собеседников с нулевым неразглашением (zero-knowledge
-password proof): пользователи могут задать друг другу вопросы и сравнить
-известные только им ответы, без утечки какой-либо информации о самих
-ответах в сеть. То есть, даже если между вами окажется
-человек-по-середине (man-in-the-middle), то он не сможет узнать ответы и
-использовать их для аутентификации позже. Вы можете использовать SMP
-протокол при каждом сеансе связи для того чтобы убедиться в подлинности
-человека на противоположной стороне: ведь у человека силой могут
-скомпрометировать его ключ OTR или он мог просто его поменять или
-потерять.
-
-@end itemize
-
-OpenPGP имеет другую нишу использования, он хорошо справляется с иными
-задачами чем специализированные для real-time communication системы.
+++ /dev/null
-@node FAQ Telegram
-@section Безопасен ли Telegram?
-
-@strong{Ни в коем случае}. Сосед вряд ли сможет прочитать ваши
-сообщения, но сами сервера Telegram или спецслужбы смогут без проблем.
-
-В данном разделе рассматривается только @emph{MTProto} протокол
-шифрования. MTProto и соответствующий конкурс по его взлому являются
-классическим примером
-@url{https://www.schneier.com/crypto-gram/archives/1999/0215.html#snakeoil, шарлатанской криптографии}.
-
-Более подробная информация, небольшой анализ на английском есть
-@url{http://unhandledexpression.com/2013/12/17/telegram-stand-back-we-know-maths/, тут} и
-@url{http://www.cryptofails.com/post/70546720222/telegrams-cryptanalysis-contest, тут}.
-
-@menu
-* Отсутствует аутентификация пользователя: FAQ Telegram аутентификация.
-* DH использует сервер: FAQ Telegram DH сервер.
-* Априори известные небезопасные алгоритмы: FAQ Telegram алгоритмы.
-* Но конкурс по взлому же никто не выиграл!: FAQ Telegram конкурс.
-* Но ведь его написали сильные математики!: FAQ Telegram математики.
-@end menu
-
-@node FAQ Telegram аутентификация
-@subsection Отсутствует аутентификация пользователя
-
-Это самый серьёзный и фатальный (после чего его бессмысленно
-использовать) недостаток. При установлении соединения между
-пользователями они никак не аутентифицируют друг друга. То есть
-пользователь не знает действительно ли он разговаривает с нужным ему
-собеседником или с сервером который просто переотправляет собеседнику
-сообщения. То есть это то что называется атакой человек-по-середине.
-
-@node FAQ Telegram DH сервер
-@subsection DH использует сервер
-
-Первый выложенный исходный код протокола имел код при котором в
-протоколе Диффи-Хельмана принимал участие и сервер: от него принимались
-данные которые надо было подмешивать в DH сообщения. Потенциально он мог
-полностью ослабить общий установленный ключ, опять же сведя безопасность
-на нет и для внешнего наблюдателя (не только для серверов Telegram).
-
-Это похоже исправили и убрали, мотивируя тем что это была защита от
-устройств где плохой генератор случайных чисел. Возможно действительно
-было сделано не со зла.
-
-@node FAQ Telegram алгоритмы
-@subsection Априори известные небезопасные алгоритмы
-
-Любое сообщение должно быть зашифровано и аутентифицировано (то есть
-добавлена информация гарантирующая что сообщение пришло именно от
-нужного пользователя и без изменений). Как правило используют код
-аутентичности сообщения (MAC) для аутентификации.
-
-Есть разные варианты порядка как провести шифрование и аутентификацию:
-
-@table @asis
-@item Encrypt-then-MAC
-Зашифровать, затем добавить MAC от шифротекста (так делают в IPsec)
-@item MAC-then-Encrypt
-Добавить MAC от открытого текста, затем зашифровать (так делают в TLS)
-@item Encrypt-and-MAC
-Зашифровать, затем добавить MAC от открытого текста (так делали в SSH)
-@end table
-
-Первый вариант @strong{всегда} правильный и не имеет недостатков. Второй
-вариант при некоторых режимах работы даёт возможность очень серьёзных
-атак типа @url{https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack, BEAST}
-и в целом @url{http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.5488&rep=rep1&type=pdf, не может считать безопасным}.
-Третий даёт ещё большее количество атак, но на момент создания SSH об
-этом мир криптографии ещё просто не знал. Не имеет смысла использовать
-ничего кроме первого варианта.
-
-MTProto использует фактически третий вариант. Если при первом варианте
-нужно будет вычислить например HMAC и если он даст отрицательный
-результат, то больше ничего не предпринимать, то в MTProto нужно
-вычислить И хэш И дешифровать сообщение чтобы понять что оно не
-аутентифицировано. То есть самая плохая производительность и
-безопасность.
-
-SHA1 используемый MTProto является устаревшим алгоритмом, не безопасным
-для современного использования. Telegram говорит что он выбран из-за
-производительности. Возможно и так, но он не намного медленнее (на
-современных процессорах) SHA2, который безопасен.
-
-Более того, MTProto использует
-@url{https://www.mgp25.com/AESIGE/, IGE режим шифрования}
-более никому не известный. Абсолютно непонятно зачем. Если им надо было
-достичь того что ошибка дешифрования распространялась бы и дальше, то
-почему не использовать
-@url{https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher_Feedback_.28CFB.29, CFB}?
-В любом случае если есть аутентификация сообщений, то error propagation
-не имеет никакого смысла. Разумнее было бы выбрать например режим
-счётчика
-@url{https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Counter_.28CTR.29, CTR},
-позволяющий распараллеливать шифрование и дешифрование.
-
-Ключ шифрования зависит от открытого текста. В целом это плохо. Это
-возможные атаки, статистический анализ, но не означает что фатально.
-Ничто не мешало бы сделать ключ независимым от открытого текста.
-
-Кроме того, получается что для каждого сообщения необходимо проводить
-процедуру инициализации AES ключа -- это дорогая (медленная) операция.
-Везде стараются не менять ключ блочного шифра как можно дольше ради
-производительности.
-
-@node FAQ Telegram конкурс
-@subsection Но конкурс по взлому же никто не выиграл!
-
-И вряд ли выиграет, так как практически всегда подобные конкурсы
-@url{http://www.thoughtcrime.org/blog/telegram-crypto-challenge/, должны настораживать}
-и не несут
-@url{https://www.schneier.com/crypto-gram/archives/1998/1215.html#contests, никакого смысла}.
-
-@itemize
-
-@item Конкурсы нечестны. Они часто выставляют условия не
-соответствующие реальному миру, реальным атакам. Telegram предлагает
-перехватить шифротексты и их дешифровать, но не даёт возможности
-проводить общение с сервером или пользователям, не даёт проводить анализ
-шифротекста зная открытый текст (known plaintext attack), не даёт
-отправлять и смотреть реакцию на специально подготовленный открытый
-текст (chosen plaintext attack) или шифротекст (chosen ciphertext
-attack). То есть это можно сравнить с: попробуйте взломать мою квартиру,
-но условимся что вы безрукий инвалид без инструментов.
-
-@item Конкурсы не компенсируют затраты за взлом. Telegram не предлагает
-показать как можно совершить атаку, а предлагает её выполнить до конца.
-Криптография, криптоанализ может показать что, например, вам надо
-перехватить сообщение и сделать перебор каких-нибудь данных в количестве
-2**64. Это криптографически несерьёзное число: с ним могут справится
-суперкомпьютеры которые есть у многих корпораций и государств, но нет
-у простых людей. Аренда вычислительных мощностей для проведения 2**64
-операций может стоить дороже чем выигрыш в конкурсе.
-
-@end itemize
-
-Поэтому участвовать в конкурсах и не выгодно и не интересно.
-
-@node FAQ Telegram математики
-@subsection Но ведь его написали сильные математики!
-
-Сильный математик не означает криптограф (тем более сильный). На данный
-момент в их протоколе множество недочётов свойственных новичкам (либо
-сделанных специально для облегчения жизни тем кто хочет дешифровать).
-Дуров в первую очередь деловой человек, а приватность пользователей
-вредна для любого бизнеса.
Почему криптография? Потому-что это математика: её нельзя подкупить, она
не может обмануть или предать, у неё нет руководящей компании -- это
-единственное на что можно положиться в этом мире (в отличии от людей) и
-довеÑ\80Ñ\8fÑ\82Ñ\8c.
+единственное на что можно положиться в этом мире и доверять, в отличии
+оÑ\82 лÑ\8eдей.
-Чтобы люди больше могли узнать о криптографии шифропанки проводят
-@ref{Cryptoparty}. В разделе @ref{Ссылки, полезных ссылок} вы найдёте
+Чтобы люди больше могли узнать о криптографии шифропанки (и не только)
+проводят @ref{Cryptoparty}. Ответы на некоторые вопросы можно найти в
+@ref{FAQ} разделе. В разделе @ref{Ссылки, полезных ссылок} вы найдёте
информацию о рекомендуемом инструментарии для сохранения приватности.
-В @url{http://git.cypherpunks.ru/, репозитории исходных кодов} этого
-ресурса имеется несколько свободных полезных программ. Кроме того, вы
-можете использовать @ref{Tracker, BitTorrent tracker} для обмена
-файлами.
@strong{Обязательное} (но не достаточное) условие для безопасности и
реализации криптографии: использование исключительно
* Cryptoparty::
* Встреча для подписи ключей (PGP keysigning party): KSP.
* Часто задаваемые вопросы: FAQ.
-* Технические статьи: Статьи.
* Полезные ссылки: Ссылки.
* BitTorrent tracker: Tracker.
* IRC (чат) сервер: IRC.
@include manifests/index.texi
@include cryptoparty/index.texi
@include ksp/index.texi
-@include faq/index.texi
-@include articles/index.texi
+@include faq.texi
@include links.texi
@include tracker.texi
@include irc.texi