to post messages and comments.

*пароли *шифрование
2016-08-20T14:00+0600 OMST (двадцатого августа 2016 года в 14 часов дня по омскому времени) Омская группа пользователей Linux (#OmskLUG) проводит Crypto Install Fest <cif.pirate-party.ru> (#CIF2016) в Омском ITLoft <itlft.ru> (г. Омск, ул. Учебная, 83, второй этаж, каб. 212 <openstreetmap.org>).
Подробности тут: omsklug.com <omsklug.com>

Собственно тезис о том, что приличным людям шифрование не нужно, имеет под собой основание.
В Нидерландах остановлена работа оператора шифрованной мобильной связи из-за криминальной активности
securitylab.ru

Несколько вопросов сразу

1. По ключу можно понять, каким алгоритмом (для какого алгоритма?) он сделан

2. Как производится подпись? известный кусок данных шифруется приватным ключем и потом получаель дешифрует публичным и сравнивает этот кусок данных?

дальше haskell specific:

3. Как скажем проверить подпись в великом и ужасном cryptonite (https://hackage.haskell.org/package/cryptonite-0.2/docs/Crypto-PubKey-RSA-PKCS15.html#v:decrypt), т.к. смотрю я тут на decrypt и что-то подсказывает, что он приватный ключ хочет. В целом там есть verify, но он как-то прекрасно документирован, плюс на данном этапе мне достаточно проверить первые 20 байт куска данных, а не полностью

Если есть key-value storage, в котором values зашифрованы на чем-то, выведеном из master secret, то какие есть правильные способы смены ключей? Ничего лучше, чем писать апдейты на новых ключах и в фоне перешифровывать остальное, пока не придумывается.

прикрутил шифрование ГОСТ, пока только в ручном режиме
crypto# ipsecctl -sa
FLOWS:
flow esp in from 192.168.8.0/24 to 192.168.7.0/24 peer 192.168.56.102 type require
flow esp out from 192.168.7.0/24 to 192.168.8.0/24 peer 192.168.56.102 type require

SAD:
esp tunnel from 192.168.56.101 to 192.168.56.102 spi 0xabd9da39 auth hmac-gost enc gost-ecb
esp tunnel from 192.168.56.102 to 192.168.56.101 spi 0xc9dbb83d auth hmac-gost enc gost-ecb

В продолжение #2513200.
А для hackage.haskell.org генератора код из gist.github.com работает как ожидается.
Посмотрел я на реализацию Crypto.PubKey.DSA.sign — она использует, в итоге, withRandomBytes, а она, в свою очередь, cprgGenerate.
Собственно отсюда следует, что не стоит полагаться на реализацию SystenRNG, т.е. лучше вернуть IORef с генератором.

Господа гляньте плз код gist.github.com . Если расскомментить 14 строку и закоментить 13-ю вывод не измениться. Кажется ли это вам нормальным?
Собственно есть библитека Crypto.Random hackage.haskell.org замечательного параноика Vincent Hanquez . Он её запилил на замену своей же Crypto.Random.API . С предыдущей версией я просто хранил глобально IORef на какой-то системный инстанс CPRG и в ус не дул, просто подменял при использовании старый генератор на новый. Сейчас же появился EnthropyPool который держит байтстринг и MVar с текущей позицией в нём и каждый раз при вызове генератора обновляет этот MVar. При таком раскладе можно просто хранить глобальный EnthropyPool . Это здорово, но меня как-то напрягает смена подхода без смены интерфейса. Нафига тогда генератор возвращать?
ЗЫ Винсенту я уже написал, он пока молчит. Хочется знать ваше мнение.

Чят, подскажи актуальное решение для криптоконтейнера со стеганографией? Прочитал, что трукрипт якобы умеет размещаться в неаллоцированном пространстве раздела и просить не затирать себя, но чото не верится.

FreeC: Tomb

ФриКод: freecode.com
Сайт: dyne.org

Licenses GPLv3
Operating Systems GNU/Linux
Implementation zsh, C, GTK2+

Tomb система шифрования, сильная и устойчивая к взлому и легкая в повседневном использовании. Tomb по сути представляет собой закрытую директорию, что позволяет безопасно перемещать ее, а так же прятать в недрах файловой системы. Ключи для каждой такой "могилы" (директории) хранятся отдельно, так что вы можете, к примеру, хранить закрытую "директорию" на вашем компьютере, а ключ от нее на USB-носителе. Код Tomb достаточно прост для проверки (просмотра) и базируется на использовании нескольких общих компонентов (shared components). Сама программа состоит из скрипта на ZShell и десктопного приложения. Внутренний же механих Tomb использует стандартные утилиты GNU, а так же криптографический API ядра Linux (dm-crypt) доступный через cryptsetup.

Релиз: 1.4 (20 Jun 2013 21:38)
Этот релиз исправляет критическую ошибку в версии Tomb 1.3, которая препятствовала обратной совместимости и делала ключи созданные в этой версии нерабочими.
Кроме того добавлено несколько новых "фич" как индексация и поиск по содержимому "могилы", "гравировка" ключа в QRCode (что позволяет сохранить его на бумаге), так же функцию setkey, которая позволяет заменить один ключ на другой. Улучшено симметричное шифрование ключа, возможен выбор шифра с помощью опции -o (по умолчанию AES256).
Как уже было упомянуто, этот релиз возвращает обратную совместимость со старыми "могилами", так что всем пользователям старых версий настойчиво рекомендуется про-ugrade-ится до данной версии.

Отсебятина:

Программка достаточно интересная, особенно в свете того, что шифрование становится в общем-то трендом нашего времени.
Однако самая большая проблема этой (и многих других подобных проектов) натыкается на проблему необходимости root-прав для ее использования.
Таким образом использование в корпоративной среде сразу становится практически невозможным. Root-права имеются только у админов. Вариант с настройкой sudo, конечно, возможен, но и мороки уж больно много, и раздавать так много sudo тоже, к примеру, не хочется.
На локальном, домашнем, компе, ее конечно, использовать можно. Но даже и здесь, жонглирование между root-ом и пользовательскими данными вызывает некие... немного неприятные ощущения.
Так что а) если очень надо — то конечно, это в общем-то неплохой вариант;
б) с другой стороны есть наверное и другие варианты;

В итоге, один из главных плюсов программы — забавность пользовательского интерфейса (в коммандной строке, конечно).
Для создания "могилы" используется команда "копать": tomb dig secret.tomb -s 100

Для создания ключа — команда "ковать" : tomb forge -k secret.tomb.key

После чего выкопанную могилу можно закрыть выкованным ключом: tomb lock secret.tomb -k secret.tomb.key

Кроме того, еще пара любопытных "фич" : ключ можно так же захоронить (aka спрятать) — bury — внутри jpeg-файла. Ну или "выгровировать" в виде QR-кода.

Захотел тут подгенерить себе соли. Нашёл аж 2 Crypto.Random и Crypto.Random.API , для того чтоб взять десяток другой случайных байт. И думаю может ну его нафиг, Tibel в hashable берёт всё тупо из /dev/urandom и System.Entropy мой выбор?

Вопрос к спецам по криптографии. Разбираюсь с алгоритмом блочного шифрования на основе сети Фейстеля. Данные разбиваются на блоки (допустим 8 байт). Если в последнем блоке данных меньше, то блок удлиняется до нужного размера. Как при расшифровке определить исходный размер последнего блока?

а вы когда-нибудь обращали внимание, что почти половина людей (если они не недавние студенты), когда их просишь рассказать, как работает RSA, описывают вместо нее криптосистему Рабина?

Как вам ? Толсто ?
Предназначенна для использования на территории Таможенного союза России, Белоруссии и Казахстана. В микропрограмме реализована поддержка туннелей IPSec с шифрованием DES (длина ключа 56 бит) и NULL.