Привет, %username%! Бывает необходимо генерировать ID не подряд, причем чтобы они гарантированно не повторялись. На youtube это используется для того, чтобы вы не могли брутфорсом получить все новые и старые видосики, так же это не редкость на разных файлообменниках и вообще везде где нужно предотвратить или хотя бы затруднить возможность прямого перебора значений.


К примеру, в системе moodle, которая использовалась у нас в универе для тестирования студентов, ID ответов были инкрементными и сквозными на всю базу. Логично предположить, что правильным ответом был тот, что с наименьшим ID в пределах вопроса. В общем, проблем с тестами у нас не было. Потом они перешли на GUID, но я к тому моменту уже выпустился, хехе.

Давайте рассмотрим несколько способов генерации таких ограниченных по длине последовательностей от самых простых до криптографически стойких.

Привет, %username%! Сегодня у нас немного пятничная криптотема. В марте 2016 года вышла интересная публикация от NIST под номером 800-38G (pdf) и с очень интересным называнием Recommendation for Block Cipher Modes of Operation:Methods for Format-Preserving Encryption, в которой отписываются два алгоритма, позволяющие не менять формат данных при шифровании. То есть, если это будет номер кредитки 1234-3456-4567-6678, то после шифрования он тоже останется номером, просто другим. Например 6243-1132-0738-9906. И это не простой xor, там AES и вообще всё серьезно. Давайте немного поговорим о FPE вообще, и об одной из реализаций в частности.

Привет, Хабр!
Несмотря на набирающие все большую популярность мобильные мессенджеры, такие как WhatsApp и Telegram, старые добрые SMS все еще не теряют свою актуальность. SMS можно использовать для отправки разного рода уведомлений, для двухфакторной аутентификации или при сбросе пароля. Однако последние успешные атаки на мобильные сети заставляют задуматься о дополнительном уровне защиты передаваемых с помощью SMS данных.
В этой статье мы поговорим о том, как используя сервисы Virgil и Twilio, сделать процесс отправки SMS на Android устройства безопасным.

Введение

Написание технического документа — трудное дело. Чтение плохо написанного технического документа является более трудным и, вероятно, более болезненным делом, чем его написание. Требуется большая работа, чтобы создать ясное, точное, интересное техническое описание. Поэтому, чтобы сделать жизнь хоть немного проще для всех участвующих сторон, я хотел бы поделиться с вами семью правилами, которым я следую, создавая техническую документацию.

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

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

Итак — эти 7 правил:

1. Скука убивает
2. Прежде чем начать, выясните точно для себя, какие действия вы ожидаете от читателя, осилившего ваш труд
3. Пишите в соответствии с правильно сформированной структурой
4. Избегайте неоднозначных местоимений
5. Ясность = иллюстрации + слова
6. Когда имеете дело с понятиями, концепциями и т.п., используйте логическую иллюстрацию и пример
7. Не опасайтесь переделок

Привет!
Мы уже показывали вам код, с помощью которого можно легко и просто реализовать end-to-end шифрование. Давайте пойдем дальше и, используя сервисы Virgil Security, разработаем безопасный IP мессенджер. Реализация безопасного IP мессенджера со встроенной функцией шифрования – задача далеко не тривиальная. В этой статье мы хотим рассказать как, используя Virgil API и Тwilio IP Messaging API, сделать этот процесс намного проще.

Привет, Хабр!
В комментариях к нашему первому посту народ требовал хлеба и зрелищ кода и «success story». И если с первым у нас все более-менее нормально, то со вторым чего-то, как-то не складывается пока. Мы, знаете ли, люди все молодые, успехи у нас достаточно скромные, в баскетбол вот неплохо играем. Одним словом, сегодня мы пока просто немного покодим и раскажем о реализации end-to-end шифрования с использованием наших сервисов. А «success story»? Какие наши годы, будут еще в нашем блоге эти самые success stories.

Привет!
Я уже писал на Хабре о своей реализации блочных шифров стран СНГ. Выдалась еще одна свободная неделька в результате чего к симметричным стандартам добавились алгоритмы электронной цифровой подписи: российский ГОСТ 34.10-2012, украинский ДСТУ 4145-2002 и белорусский СТБ 34.101.45-2013.
Все три алгоритма основаны на эллиптических кривых. Но реализация каждого из стандартов имеет свои тонкости, о которых я хочу кратко рассказать в этой статье.

Шифрование. Вопрос, к которому многие разработчики подходят с благоговением и опаской. За последние пару десятков лет многие пытались изменить этот неидеальный мир и многие достигали успеха. Но одна вещь оставалась неизменной — создать безопасное приложение до сих пор могут позволить себе далеко не все. Цена безопасности слишком велика и включает в себя изучение десятков стандартов и спецификаций, компиляцию тонн непонятного кода, чтение многостраничных монографий криптографических гуру. Мы в Virgil Security далеки от амбициозных планов по изменению мира, мы просто хотим сделать безопасность доступной каждому. И вот мы на Хабре, здравствуйте!