"Никогда не пишите свою собственную криптографию" -- говорили они. Но сейчас любой школьник с удовольствием перетасует байты зашифрованного файла -- и вот вам "новый алгоритм"! Сколько честных криптостойких алгоритмов могли использовать простые люди? Пять? Десять?? А сейчас их появятся ТЫСЯЧИ! https://ders.by/crypt/derscrypt2/derscrypt2.html
«Мы хотим гарантировать, что у ЦРУ всегда будет доступ к вашим файлам, приложениям и паролям»
...не забывайте систематически шифровать Информацию! Помните, что абсолютно все современные операционные системы, доступные обывателю, являются шпионами. Их главная обязанность -- фильтровать всю доступную информацию и автоматически отправлять кому следует. https://ders.by/crypt/derscrypt2/derscrypt2.html
Постарайтесь внимательно проследить за ходом его мысли. По мере того как вы будете вникать в суть рассуждений Эйнштейна, вы вдруг поймаете себя на том, что...
...сжимаете кулаки!
а давайте-ка напомним еще одну "теорию заговора", как водится, оказавшуюся правдой: GPS! знаете ли вы, что спутники GPS не делают поправки на теорию относительности?
большую часть времени программист тратит на обдумывание
да.
и на отладку кода
НЕТ!
"продуманный" код в отладке почти не нуждается. а если кто-то долго отлаживает СВОЙ СОБСТВЕННЫЙ код, то это плохой кодировщик ;)
вопрос даже не в скорости мыслительного процесса
как сто слепых не заменят одного зрячего, так и сто дураков одного умного.
задачи "умного" не пересекаются с остальными. и в пределе тут нет фактора Времени, т.к. представители интеллектуального большинства вообще не решат Задачу.
На эту работу нас подвигло желание узнать, почему в программной инженерии некоторые люди на порядок, а то и два, полезнее большинства людей. Если бы так было у каменщиков, то строительная индустрия очень заинтересовалась бы причиной. Проблема, конечно, в том, что о каменщике за работой можно снять фильм, а затем его действия проанализировать. Но невозможно увидеть, что делают великие программисты, да и они сами не смогли бы объяснить разницу, хотя большинство из них и захотело бы это сделать. ... Достижение понимания происходящего заняло долгое время, хотя ключевые идеи уже давно известны большинству из нас. По пути мы изучили склад мышления достигших успеха программистов и смогли разработать упражнения, которые обязательно помогут многим. Этот материал создавался несколько лет и является смесью идей, эмпирически подправленных экспериментами и позднее собранных в единую логичную картинку, а также материала, полученного на основе этой картинки.
Цель этой работы -- донести элементы "опыта" или "взглядов", на которые повсеместно ссылаются, но редко описывают. Многие темы -- это то, что программисты обсуждают за пивом. Кажется странным, что никто не стремится узнать, как проблемы, которые программисты считают наиболее важными, соотносятся с "формальными" структурами современной инженерии. Здесь мы делаем именно это.
Если мы попали в точку, большинство программистов получают удобный случай поместить волновавшие их долгие годы проблемы в ясный рабочий контекст. Мы предлагаем расслабиться и хорошо провести время!
интересно?
узкий круг ограниченных лиц применяет это на практике... вы не поверите СКОЛЬКО лет!
привет, рад новой встрече! в своей прошлой статье вы так и не дали ВНЯТНОГО ответа. зело продолжим:
Дано. Для "повышения безопасности", вы храните в ПровайдереСекретов Секреты для доступа к Серверам. Вопрос: Где вы храните Секреты для доступа к самому ПровайдеруСекретов?
There’s something worrying about this bug: I was the first to discover it, in January 2017. According to Khovratovich himself, it was two years old. Now I understand why the authors themselves didn’t find it: unlike me, they didn’t have a reference implementation to compare to.
What I don’t understand is, how come nobody else ? If you implement Argon2 from spec, you cannot miss it. Test vectors won’t match, and searching for the cause will naturally lead to this bug. I can draw only one conclusion from this:
I’m the first to independently re-implement Argon2.
This “never implement your own crypto” business went a little too far.
перевожу для ленивых:
НИКТО В МИРЕ не discovered and reported this bug! Подход «никогда не пишите собственную криптографию» уже дошел до органов приседания.
если автор доступен для терморектального криптоанализа
вот! это ГЛАВНОЕ. и не важно на все остальное, если можно давить гражданина.
реализуйте безопасность всерьёз и с серьёзными затратами или не реализуйте её вовсе, потому что полумеры практически дают результат хуже чем если бы не реализовывали ничего
смиялсо.
а вот вам цитата Серьезного Безопасника из 90х годов: ЛЮБОЕ минимальное шифрование ВСЕГДА лучше ограничения прав доступа! ваш текст не должен СРАЗУ читаться. точка.
но сначала поговорим про ГОСТы ;) ГОСТ — это аббревиатура от словосочетания «государственный стандарт». он есть в любом государстве. и в любом государстве вас ЗАСТАВЯТ его использовать!
почему?
ну, прежде всего нужно четко себе представлять, что весь Мир сейчас жестоко разделен на дружественные и вражественные юрисдикции:
вражеские государства вас заставят использовать ГОСТ, потому что всегда смогут вскрыть все шифровки. они это используют для продвижения терроризма, наркомании и детской порнографии!
дружеские государства вас заставят использовать ГОСТ, потому что всегда смогут вскрыть все шифровки. они это используют для защиты от терроризма, наркомании и детской порнографии!
не перепутайте!
и что же крестьянину делать? 2. обязательно использовать ГОСТ страны пребывания. это Закон!
1. но перед этим шифровать свои данные любым доступным способом.
да, есть подвох. сразу после вашего наивного шифрования (но перед ГОСТом) его нужно чуточку исказить:
на текущий момент у статьи 3.5K просмотров. и раз каждый второй здесь Эксперт С++, то хотя бы 1 из 100 просмотрели оригинал https://cacm.acm.org/blogcacm/21st-century-c/ . значит 70 глаз как минимум!
кто-то нашел ошибки у Страуструпа? ха! да ни один ;)
ну, например:
import std;
using namespace std; // make all of the standard library available
vector<string> collect_lines(istream& is) // collect unique lines from input
{
unordered_set s; // hash table
for (string line; getline(is,line); )
s.insert(line);
return vector{from_range, s}; // copy set elements into a vector
}
unordered_set s; - это блин что такое? опять на весь Мир рукожопие??
все эти аллокаторы нужны либо в играх либо в трэйдинге... Короче в обычной жизни даже стандартного аллокатора хватает
увы, но нет:
thread-local allocator полезен всем многопоточным приложениям. точно так же, как однопоточным не нужен std::shared_ptr с его атомиками.
а в однопоточных числодробилках mem_pool существенно увеличивает скорость и заметно уменьшает расход памяти. например, возьмите https://ders.by/cmpr/cpt/cpt.html и уберите вызов mp_set_memory_functions().
в прямом смысле замедляет работу программы в соотношении примерно 1 к 1
рост фрагментации памяти не должен превышать 2% в час
может мы обидели кого-то зря (ц)
но фразы "примерно 1 к 1" и "2% в час" - это откровенный бред! и дальше можно уже не читать...
но автора спасает фраза"TC-аллокатор переносит работу с памятью на уровень отдельного потока, предоставляя каждому собственный пул памяти. Помимо избавления от системного new/malloc, он также снижает затраты на синхронизацию", и тут уже можно что-то сказать по Теме.
короче, дальше опять будут ссылки. они позволят вам САМОСТОЯТЕЛЬНО запустить код и убедиться в ВОТ ТАКОМ росте производительности... но если это обидно, то ссылки можно не открывать ;)
второе. ders::off_pool - это использующий СМЕЩЕНИЯ thread-local allocator, позволивший реализовать хеш-таблицу с транзакциями с тридцатикратным ростом производительности! и это прямо сегодня, на современных платформах https://ders.by/cpp/memdb/memdb.html#5.2
ЗЫ уверен, вы понимаете, что мои 339.5 и 30 раз - это не голословные "примерно 1 к 1" и "2% в час" автора ;))
"Никогда не пишите свою собственную криптографию" -- говорили они. Но сейчас любой школьник с удовольствием перетасует байты зашифрованного файла -- и вот вам "новый алгоритм"!
Сколько честных криптостойких алгоритмов могли использовать простые люди? Пять? Десять?? А сейчас их появятся ТЫСЯЧИ!
https://ders.by/crypt/derscrypt2/derscrypt2.html
...не забывайте систематически шифровать Информацию!
Помните, что абсолютно все современные операционные системы, доступные обывателю, являются шпионами. Их главная обязанность -- фильтровать всю доступную информацию и автоматически отправлять кому следует.
https://ders.by/crypt/derscrypt2/derscrypt2.html
о боже, ШИКАРНЫЙ камент!
файл README там, конечно, для слабаков.
таки не поверим и внесем изменения здесь:
и здесь:
а теперь запускаем:
ну и??
ЗЫ еще раз убеждаюсь, что главная проблема C++ это некомпетентые кодировщики.
гмм, даже стало интересно!
криптография 2004-2006 года - это старый и сложный код?
берем свежий компилятор:
берем исходники DersCrypt https://ders.by/crypt/derscrypt/cpp/src.zip
и делаем:
и кроме идиотского "suggest parentheses" все прекрасно собралось и отлично работает!
ЗЫ может дело немножно в руках?
право слово, как дети...
Главная Цель любого комитета по ХХХ - гарантировать свое существование! а проблемы самого ХХХ тут дело десятое.
далее.
C++ "зашел не в ту дверь" еще при Страуструпе. но! если выбросить ерунду, то можно прекрасно ехать.
вот вы, например, чего бы хотели выбросить??
https://ders.by/cpp/norefs/norefs.html
...сжимаете кулаки!
а давайте-ка напомним еще одну "теорию заговора", как водится, оказавшуюся правдой: GPS!
знаете ли вы, что спутники GPS не делают поправки на теорию относительности?
всё. точка! любой физик поймет, что это значит.
да.
НЕТ!
"продуманный" код в отладке почти не нуждается.
а если кто-то долго отлаживает СВОЙ СОБСТВЕННЫЙ код, то это плохой кодировщик ;)
как сто слепых не заменят одного зрячего, так и сто дураков одного умного.
задачи "умного" не пересекаются с остальными. и в пределе тут нет фактора Времени, т.к. представители интеллектуального большинства вообще не решат Задачу.
о! а вот это прямо по теме:
интересно?
узкий круг ограниченных лиц применяет это на практике... вы не поверите СКОЛЬКО лет!
The Programmers' Stone https://ders.by/pp/ps/index.html
это правильный ответ.
небезопасно хранить Секреты доступа к ПровайдеруСекретов - это глупо. а их невозможно хранить иначе.
привет, рад новой встрече!
в своей прошлой статье вы так и не дали ВНЯТНОГО ответа. зело продолжим:
Дано. Для "повышения безопасности", вы храните в ПровайдереСекретов Секреты для доступа к Серверам.
Вопрос: Где вы храните Секреты для доступа к самому ПровайдеруСекретов?
очень жаль, что никто не читает ссылки...
перевожу для ленивых:
НИКТО В МИРЕ не discovered and reported this bug!
Подход «никогда не пишите собственную криптографию» уже дошел до органов приседания.
да, Страуструп мне сразу ответил:
Correct. Will fix in my own version. Thanks.
отличная Тема! и мои пять копеек :)
вот! это ГЛАВНОЕ.
и не важно на все остальное, если можно давить гражданина.
смиялсо.
а вот вам цитата Серьезного Безопасника из 90х годов: ЛЮБОЕ минимальное шифрование ВСЕГДА лучше ограничения прав доступа! ваш текст не должен СРАЗУ читаться. точка.
но сначала поговорим про ГОСТы ;)
ГОСТ — это аббревиатура от словосочетания «государственный стандарт». он есть в любом государстве. и в любом государстве вас ЗАСТАВЯТ его использовать!
почему?
ну, прежде всего нужно четко себе представлять, что весь Мир сейчас жестоко разделен на дружественные и вражественные юрисдикции:
вражеские государства вас заставят использовать ГОСТ, потому что всегда смогут вскрыть все шифровки. они это используют для продвижения терроризма, наркомании и детской порнографии!
дружеские государства вас заставят использовать ГОСТ, потому что всегда смогут вскрыть все шифровки. они это используют для защиты от терроризма, наркомании и детской порнографии!
не перепутайте!
и что же крестьянину делать?
2. обязательно использовать ГОСТ страны пребывания. это Закон!
1. но перед этим шифровать свои данные любым доступным способом.
да, есть подвох.
сразу после вашего наивного шифрования (но перед ГОСТом) его нужно чуточку исказить:
переставить немножко байтики
что-то заксорить во имя тёщи
в общем, любое дилетантское искажение, делающее невозможным АВТОМАТИЧЕСКОЕ декодирование "всем известного" наивного шифрования...
вы тем самым поможете Злым человекам стать немножко Добрее.
забавно...
на текущий момент у статьи 3.5K просмотров. и раз каждый второй здесь Эксперт С++, то хотя бы 1 из 100 просмотрели оригинал https://cacm.acm.org/blogcacm/21st-century-c/ . значит 70 глаз как минимум!
кто-то нашел ошибки у Страуструпа? ха! да ни один ;)
ну, например:
unordered_set s; - это блин что такое? опять на весь Мир рукожопие??
прэлесно (ц)
вот здесь у вас точный список
а тут уже ВСЕМ капут!
вот так, шаг за шагом, "мелкие мелочи" превращают ваш билд в каку... а кто это сделал? (ц)
Любой мужчина в возрасте внезапно для себя осознает, что ему уже не хватает синхронизированной хеш-таблицы...
в общем, попробуйте Хеш-таблицу с транзакциями: ее функционал и эффективность точно выше. https://ders.by/cpp/memdb/memdb.html#5.2
вы что-нибудь слышали о GMP?
https://en.wikipedia.org/wiki/GNU_Multiple_Precision_Arithmetic_Library
увы, но нет:
thread-local allocator полезен всем многопоточным приложениям. точно так же, как однопоточным не нужен std::shared_ptr с его атомиками.
а в однопоточных числодробилках mem_pool существенно увеличивает скорость и заметно уменьшает расход памяти. например, возьмите https://ders.by/cmpr/cpt/cpt.html и уберите вызов mp_set_memory_functions().
гмм... гуглим setenv и видим:
функцию setenv небезопасно вызывать в многопоточной среде? да ладно!
как нет-то :D
может мы обидели кого-то зря (ц)
но фразы "примерно 1 к 1" и "2% в час" - это откровенный бред! и дальше можно уже не читать...
но автора спасает фраза "TC-аллокатор переносит работу с памятью на уровень отдельного потока, предоставляя каждому собственный пул памяти. Помимо избавления от системного new/malloc, он также снижает затраты на синхронизацию", и тут уже можно что-то сказать по Теме.
короче, дальше опять будут ссылки. они позволят вам САМОСТОЯТЕЛЬНО запустить код и убедиться в ВОТ ТАКОМ росте производительности... но если это обидно, то ссылки можно не открывать ;)
итак.
первое. ders::mem_pool - это thread-local allocator, который еще в 2009 году добился 339.5 кратного роста производительности https://ders.by/cpp/mtprog/mtprog.html#3.1.1
второе. ders::off_pool - это использующий СМЕЩЕНИЯ thread-local allocator, позволивший реализовать хеш-таблицу с транзакциями с тридцатикратным ростом производительности! и это прямо сегодня, на современных платформах https://ders.by/cpp/memdb/memdb.html#5.2
ЗЫ уверен, вы понимаете, что мои 339.5 и 30 раз - это не голословные "примерно 1 к 1" и "2% в час" автора ;))