Алгоритм RSA является одним из первых представителей асимметричной криптографии, прошедший свой путь сквозь бурные дискуссии математиков, сквозь сотни успешных и безуспешных попыток взлома криптоаналитиками, сквозь тысячи неправильных применений и реализаций.

В настоящее время алгоритм RSA уже постепенно и планомерно заменяется асимметричной криптографией на эллиптических кривых за счёт сохранения старого уровня безопасности с меньшей длиной ключа. Но всё же, он до сих пор занимает лидирующие позиции по своему применению и вполне оправданно, учитывая его относительно долгую историю для раздела асимметричной криптографии.

На хабре алгоритм RSA не раз обсуждался и критиковался, как например тут, тут, тут, но весь анализ сводился либо к анализу конкретного недостатка / уязвимости, либо к неправильному использованию / применению старого стандарта. Всё это неплохо, но не даёт полной картины того, чем всё же может быть опасна чистая математическая структура алгоритма RSA.

Что такое строка? Какие бывают строки? Как они хранятся внутри движка. Подробно разберем все детали и особенности.

В предыдущей статье я рассказал об общих принципах поиска больших простых чисел. Но как бы ни был организован поиск, в конце он всегда заканчивается тестом простоты. И, к сожалению, иногда случается ситуация, когда простое число-то мы нашли, но доказать его простоту не можем. Например, так получилось с самым маленьким простым числом из миллиона цифр 10⁹⁹⁹⁹⁹⁹+593499. В этой статье я расскажу, почему тестам простоты уделяется так много внимания в сообществах добровольных распределённых вычислений, таких как GIMPS и PrimeGrid.

Деление целых чисел — это долго и сложно. Вычислять остаток от деления — нисколько не проще. При этом в спортивном программировании, да и в прикладной математике типа криптографии, задача умножения чисел по модулю встречается повсеместно.

Один из вариантов эффективного решения — умножать по модулю, вообще при этом не используя операции деления, с помощью алгоритма Монтгомери.

Про него я и хотел бы поговорить.

Хабр, привет! Меня зовут Владимир Михайлов, я занимаюсь бэкендом в Яндекс Такси — мы создаём внутренние продукты, которые используют в разных юнитах Яндекса. Также я работаю наставником на курсах «Разработчик C++» и «C++ для бэкенда» в Яндекс Практикуме. 

А ещё я помогаю компании с наймом и провожу предварительные секции с кандидатами — разработчиками C++. Я расскажу, какие задачи даю на этих секциях, на что обращаю внимание и как подготовиться к подобному собеседованию.

Рано или поздно системный программист сталкивается с понятием firmware. В данной статье мы коротко рассматриваем, что это, зачем, и как с этим работать.

Disclaimer:
Материал не является сборником best practices и не претендует на фундаментальный труд. Это шпаргалка. Если угодно - application note в свободной форме. Основная задача материала - "сделать короткую статью, которая помогла бы лично мне быстро разобраться, если бы я впервые столкнулся с темой". Если вы знаете что-то лучше - дополнения и замечания по существу приветствуются. Мотивацией для написания послужила недавно встреченная статья, которая как раз объясняла эти аспекты не очень хорошо.

Простые числа удивительны!

С одной стороны, их легко объяснить: это просто числа, которые делятся только на единицу и на себя; с другой стороны, они содержат в себе бесконечную сложность. Они встречаются во множестве разных сфер, от математических концепций и гипотез до любопытных визуализаций и криптографии, лежат в основе многих Интернет-стандартов и протоколов безопасности, которые мы используем ежедневно.

Несмотря на моё восхищение простыми числами, я никогда не исследовал их подробно, поэтому решил бросить себе вызов. А есть ли лучший способ изучить простые числа, чем воспользоваться моей любовью к кодингу для их генерации?

Вызов

Но какие простые числа мне генерировать? Нахождение миллиардного числа — это слишком просто, а попадание в таблицу рекордов самых больших известных простых чисел — слишком амбициозная задача для первой попытки. Соединив простые числа и интерес к криптографии, я придумал такую задачу:

Генерировать простые числа, способные генерировать ключи для алгоритма RSA

На момент написания этой статьи хорошей длиной ключей RSA считаются 2048 битов. Ключи RSA генерируются перемножением двух простых чисел, так что для получения 2048-битного ключа нам нужны два числа длиной примерно 1024 бита. Это ограничивает рамки задачи генерацией 1024-битных простых чисел. Теперь вы знаете, откуда взялось число из заголовка поста.

Бизнес полон "эффективных менеджеров" и их "лучших практик". Переработки, стресс, политика кнута без пряника, урезания зарплат и премий, обманы и подлоги. Эти практики распространены очень широко, хотя нет никаких доказательств, что они работают. В этой статье я с помощью множества исследований доказываю, что "эффективный менеджмент" серьёзно проигрывает гуманному подходу в управлении людьми.

Буквально: если начать относиться к сотруднику как к взрослому сознательному человеку, заботиться о нём, давать ему адекватную загрузку и дать возможность заниматься интересными для него задачами, платить справедливую зарплату, то и отвечать он будет как взрослый человек: ответственно и старательно иметь высокую производительность труда.

В общей сложности я разбираю 10 самых распространённых ошибок "эффективных менеджеров" и показываю гуманные и более действенные подходы.

Привет любителям микро-кодирования. Вот вам кое-что невероятное: крошечный движок raycasting (метод “бросания лучей”) и генератор городов, который помещается в отдельный 256-байтовый HTML-файл.

В России выкатили новый закон о регулировании крипты, и грозятся принять его до конца текущего года. Что конкретно там запретили, какая ответственность грозит за «незаконные операции с криптой», и как дальше будут выживать отечественные криптообменники – разобрались во всём этом с профильным юристом.

Dear Habr, I am writing to share my experience... ой, кажется, я переобучилась на вариантах части Writing. В общем, я пишу эту небольшую статью, чтобы поделиться личным способом сдачи международного экзамена по английскому языку, рассказать о подготовке, мотивации и издержках.

Мое наблюдение состоит в том, что мы — разработчики и продукты, сильно переусложняем, осознанно или нет, но всякие «„Архитектурные комитеты“, „Планирования“, „Апрувы у 50 отделов“ и деплои в 2-часовые окна, простыни текста сопровождающие простейшие фичи — это просто какой‑то бич современной разработки. Умные дяди с 20 летним опытом за плечами, с невозмутимыми лицами сутки напролет на созвонах обсасывают простейшие вещи вроде замены кнопки. Что это? Следствие усложнения программного обеспечения или засилие не тех людей не на тех местах? Или следствие входа в индустрию новичков, стремящихся простое сделать сложным?

В статье мы разберем что такое „переусложнение“, дадим ему определение и на реальных примерах разберем во что это выражается и как с этим бороться.

Хотел написать продолжение к статье Что почитать игровому программисту? про использование С++ в игровых движках, но размышления свернули куда-то не туда.

Завороженно смотрю как и какими темпами идет развитие языка в последние годы, и понимаю, что получить и особенно применить возможности С++20/3 в разработке игр и движков получится хорошо, если с опозданием лет эдак в пять, как раз на следующее поколение консолей, если вообще получится. Сейчас плюсы в игрострое зависли где-то между 14 и 17 стандартом, Сони только-только выкатила свою версию компилятора с полной поддержкой 17 стандарта, а учитывая реактивность игровых студий в изменении кор пайплайнов, что-то новое начнут только в новых проектах. Менять коня, т.е. компилятор посреди разработки игры равносильно стрельбе не только по ногам себе, но и соседям программистам: работает - не чини.

Если смена компилятора и стандарта не даст гарантированного прироста скорости работы больше 5%, то бюджет и людей я не одобрю. (с)

Знакомство с кодовой базой больших движков дает понимание уровня и объёмов кода в продакшене и в тулзах, и ситуация вырисовывается такая, что эти объемы стали в индустрии, что называется "too big to fall", т.е. написать что-то новое, уровня движков вроде Unity/Unreal/Dagor на другом языке, будь он хоть в тысячу раз безопаснее и в десять раз быстрее не получится, но попытки конечно делаются. И чем дальше продолжается поддержка существующих проектов на плюсах, тем меньше возможности выбора остается.

Все попытки прикрутить сбоку скрипты, виртуальную машину второго языка, визуальные редакторы скриптов, блупринты и т.д. лишь показывает насколько громоздким стал основной механизм. А игры прекрасно продаются на текущем стеке технологий, и обосновать переезд на новый стек мифическим рефакторингом, техдолгом и новыми технологиями не удаётся, поэтому мышки продолжают плакать и потреблять кактус++.

Небольшое введение в технологии MPC и мультиподписей.

Краткое описание набора протоколов и используемой реализации мультиподписи.

Прочитал её давно, и могу с уверенностью сказать, что эта книга, которая, точно себя многократно окупила. Недавно перечитал и актуализировал для себя 5 самых ценных, с моей точки зрения, советов:

1) Не стесняться предлагать свои условия. Твердо установленных цен не существует, всегда есть пространство для переговоров.

2) Менять не цену, а пакетное предложение. Например, если тебя просят снизить цену, то сделать это можно, но только вместе с изменением других условий (состава работ, сроков выполнения, сроков платежей и др.). Слово “ЕСЛИ” в переговорах намного более полезно, чем слово “НЕТ”. Можно идти на уступки, но никогда нельзя это делать в одностороннем (тем более превентивном) порядке. 

3) Стараться не выставлять себя финальным ЛПР, а иметь за спиной, пусть даже придуманного, но “принципала”, на которого можно сослаться для изменения условий

4) С другой стороны —  всегда стараться самому вести переговоры именно с тем, кто фактически принимает решения.

5) Выявлять и учитывать позиции и интересы другой стороны (позиция —  то, что мы хотим, интересы —  почему именно). Помнить и ориентироваться на свои интересы. 

6) При любом соглашении заранее продумывать возможные “что мы будем делать, если …”

7) Фокусировать переговоры на возможных (и выгодных для каждой из сторон) решениях, а не обсуждении прошлого, в том числе заботиться, в первую очередь, об “ошибках других”, а о средствах их исправления с учетом ваших интересов.

Другие книги в тему: Фишер. Переговоры без поражений; Кемп. Сначала скажи “Нет”, Ури. Договорись с собой и другими достойными оппонентами; Паттерсон. Трудные диалоги (конспект по ссылке) и Розенберг. Язык жизни. Ненасильственное общение (конспект по ссылке)

Продолжаем серию «C++, копаем вглубь». Цель этой серии — рассказать максимально подробно о разных особенностях языка, возможно довольно специальных. Это шестая статья из серии, список предыдущих статей приведен в конце в разделе 7. Серия ориентирована на программистов, имеющих определенный опыт работы на C++. Данная статья посвящена объявлению и инициализации переменных.

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

Во многих языках программирования объявление переменных относится к довольно простым темам, но вот в C++ это не совсем так. Конечно, простые варианты обычно не вызывают затруднений, но вот более сложные случаи могут озадачить даже достаточно опытных программистов. Попробуем разобраться во всех тонкостях объявления переменных. Также рассмотрим тему инициализации, так как чаще всего переменные инициализируются вместе с объявлением.

Автор статьи Жерар Галлан известен как автор книги “WebAssembly in Action”, выпущенной Manning в 2018 году. Существует перевод его книги на русский “WebAssembly в действии” (Питер, 2022). Предыдущий обзор Состояние WebAssembly в 2022-23 годах опубликован автором в январе 2023 года. — Прим. переводчика.

Добро пожаловать в 2024 год и в нашу статью о текущем состоянии WebAssembly (Wasm)! В этой статье я займусь тем, что посмотрю, что произошло в 2023 году. Затем я выскажу свои мысли о том, что может произойти в текущем году.