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% в час" автора ;))
а зачем его покупать сразу? сервер может расти за Прибылью.
в общем, парадигма ИЗМЕНИЛАСЬ! еще лет 10 назад каждая первая статья о Масштабировании вполне резонно отмечала, что Вертикальное Масштабирование вас НЕ вывезет...
но!
на сегодняшний день ваш Бизнес сдохнет раньше, чем вы исчерпаете возможности одного Хорошего Сервера.
ЗЫ расчлененка - дополнительная Сложность! зачем себе портить Жизнь, если можно не портить?
на сегодняшний день, микросервисы - некогда и незачем!
как я уже здесь цитировал:
Если вы давно не смотрели на серверное оборудование, то обнаружите, что современные высокопроизводительные серверы — это целые датацентры в коробке! Я просто ткнул Dell и нашел следующие характеристики PowerEdge R960:
240 ядер (4 сокета по 60 ядер в каждом)
16 ТБ ОЗУ в 64 модулях DDR5 DIMM (это как 1000 приличных ноутбуков)
А если нужно хранилище, то вы можете подключить до 24 NVMe дисков — по 4 ТБ каждый, а это почти 100 ТБ высокоскоростного SSD! И если 240 ядер вам покажется маловато, то Intel анонсировала процессоры Xeon с 288... Уже прямо сейчас вы можете подключить два Xeon 6780 к PowerEdge R770 серверу, получив в общей сложности 288 ядер, по цене около USD 32k.
Большинство enterprise-scale архитектур основаны на предположении, что одной машины недостаточно для обработки требуемой рабочей нагрузки. Большинство облачных решений, особенно serverless, основаны на той же предпосылке: если вам нужно что-то масштабировать, то оно должно быть distributed! Вторым вопросом является отказоустойчивость: в распределенной, масштабируемой системе легче обработать отказ одного компонента и, таким образом, увеличить uptime.
Сколько операционных данных хранит ваше бизнес-приложение? 1 мегабайт на клиента? Тогда 1 миллион клиентов потребуют всего 1 ТБ. И у нас еще осталось довольно много свободного пространства — в оперативной памяти! 1000 запросов в секунду к in-memory database? Я почти гарантирую вам, что у вас больше, чем несколько ядер CPU будет простаивать. 10 000 запросов (40 на ядро в секунду) или даже 50 000 звучит более правдоподобно.
А как насчет отказоустойчивости? Все постоянно выходит из строя, верно? По крайней мере, так сказал Werner Vogels, но это было в 2008 году, когда AWS была немного больше, чем S3, SQS и EC2, последний из которых только что вышел из публичной бета-версии и получил SLA — возможно, это взаимосвязано. Современные серверы имеют избыточные, сменные блоки питания и вентиляторы, диски с возможностью горячей замены, а некоторые, как утверждается, даже имеют сменную оперативную память! Тем не менее, вы не будете хранить все свои данные только в оперативной памяти, а будете писать в persistent log, который позволит вам восстановить состояние системы в случае сбоя. Для большого сервера это может занять некоторое время. Например, если у вас будет 2 сбоя оборудования в год и время восстановления составляет 30 минут, то вы все равно получите 4 девятки, примерно столько же, сколько вам обещает большинство облачных сервисов. В действительности вы, вероятно, разобьете свою систему на более мелкие компоненты: на высокодоступные, и другие, которые могут позволить себе немного более длительное MTTR.
например, в IP-телефонии нужно за 100ms принять решение: разрешаем звонок или нет? по какому тарифу? вопрос: а на какое время Java-сервис зависает в мусорке?
и еще.
если падает процесс Сервиса - это проблема, но не беда. а вот когда морозится на несколько секунд, а потом продолжает как ни в чем не бывало... это уже БЕДА!
pdf называется "Distilling the Real Cost of Production Garbage Collectors"
и начинается с "Despite the long history of garbage collection (GC) and its prevalence in modern programming languages, there is surprisingly little clarity about its true cost. Without understanding their cost, crucial tradeoffs made by garbage collectors (GCs) go unnoticed."
инфа там конечно для маленьких, но будет полезна и взрослым.
ДА! я сейчас мерзко хихикаю, потирая потные ладошки)))
но никак не за производительность
вы просто не понимаете, с кем разговариваете мне еще лет 20 назад "прогрессивная общественность" пела байки про "инкрементальный GC", не делающий stop the world... даже Страуструп топил за GC в C++, а потом "вдруг" одумался ;)
очень жаль, что никто не читает ссылки...
перевожу для ленивых:
НИКТО В МИРЕ не 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% в час" автора ;))
а зачем его покупать сразу? сервер может расти за Прибылью.
в общем, парадигма ИЗМЕНИЛАСЬ! еще лет 10 назад каждая первая статья о Масштабировании вполне резонно отмечала, что Вертикальное Масштабирование вас НЕ вывезет...
но!
на сегодняшний день ваш Бизнес сдохнет раньше, чем вы исчерпаете возможности одного Хорошего Сервера.
ЗЫ расчлененка - дополнительная Сложность! зачем себе портить Жизнь, если можно не портить?
на сегодняшний день, микросервисы - некогда и незачем!
как я уже здесь цитировал:
https://www.linkedin.com/pulse/past-constraints-you-never-thought-sergey-derevyago-ien3f
люди!
таки сделайте два шага от телевизора и внимательно посмотрите, что вы тут пишете...
вот эта ДЛИННЮЩАЯ ПРОСТЫНЯ текста - разве она решает хоть одну полезную задачу?
нет!
вы Героически Боритесь с врожденными недостатками STL и копирования/перемещения С++. и вы опять проиграете!
зачем тратить время на глупости, когда уже знаете, КАК программировать в удовольствие?
а тесты производительности запускали? вдруг и правда "МНОГОКРАТНОЕ ускорение"
мой бог, Чудовищное(tm) зрелище!!! вот за это ненавидят и боятся C++.
уже давно писал и объяснял: переходите на sh_ptr/mem_pool и получите МНОГОКРАТНОЕ ускорение без мути https://ders.by/cpp/norefs/norefs.html#4.3
ЗЫ плюс научитесь различать Чудовищное...
увы, я только вышел поболтать. и никакого отношения ни к Архитектуре, ни к IP-телефонии не имею))
так спросите "в КРУПНЕЙШИХ проектах", как они тюнят GC. и что все равно происходит.
ок, давайте посмотрим на Архитектуру.
например, в IP-телефонии нужно за 100ms принять решение: разрешаем звонок или нет? по какому тарифу?
вопрос: а на какое время Java-сервис зависает в мусорке?
и еще.
если падает процесс Сервиса - это проблема, но не беда.
а вот когда морозится на несколько секунд, а потом продолжает как ни в чем не бывало... это уже БЕДА!
только на мелких проектах.
ну, давайте читать вместе:
pdf называется "Distilling the Real Cost of Production Garbage Collectors"
и начинается с "Despite the long history of garbage collection (GC) and its prevalence in modern programming languages, there is surprisingly little clarity about its true cost. Without understanding their cost, crucial tradeoffs made by garbage collectors (GCs) go unnoticed."
инфа там конечно для маленьких, но будет полезна и взрослым.
ДА!
я сейчас мерзко хихикаю, потирая потные ладошки)))
вы просто не понимаете, с кем разговариваете
мне еще лет 20 назад "прогрессивная общественность" пела байки про "инкрементальный GC", не делающий stop the world... даже Страуструп топил за GC в C++, а потом "вдруг" одумался ;)
короче, в https://www.linkedin.com/pulse/how-java-garbage-collection-works-sergey-derevyago-af84f есть ссылки прямо по теме. постарайтесь понять ЧТО там написано Специалитами.
Жаба - это не только расход памяти. GC жабы - позор.
как и все остальные, вы сейчас не учитываете один маленький, но очень ключевой момент:
читайте https://ders.by/arch/scale/scale.html