В самом коде никаких ключей не должно быть, это правило.
Желательно сделать отдельный сервер аутентификации и шифрования, на котором никаких веб-интерфейсов не будет и который зафаерволлен нафиг. А доступные из веб-морды сервисы аутентификации и шифрования на этом криптосервере только и умеют, что по максимально простым протоколам принимать пароли и данные, и отдавать флаг да/нет, данные зашифрованные/расшифрованные, и т.д.
К серверу аутентификации, в зависимости от масштабов задачи, можно подключать железные криптоускорители и токены/смарткарты с ключами к ним. На нем можно поднять полнодисковое шифрование, а ходить на него только по полужелезной консоли через IP-KVM от провайдера. Тогда угнать БД у Вас сможет только тот, кто имеет физический доступ к серверу (надеюсь, что удаленно эксплуатируемых через веб-морду уязвимостей в самих службах шифрования на выделенном криптосервере не будет).
И не забывайте, что пароли, которые доступны пользователям и менеджерам сами по себе только «ключи» для доступа к закрытым ключам, данные шифруются вообще сеансовыми симметричными ключами, а закрытый ключ можно зашифровать чем угодно.
Главное, чтобы можно было по предоставленным субъектом данным аутентификации понять, что данному субъекту можно дать доступ к некоторому, по сути, сервису, который расшифрует ему конкретные данные.
Разумеется, мастер-пароль для основного закрытого ключа в этом варианте доступен только некоторому выделенному коду. Он аутентифицирует и авторизует менеджеров (а можно и пользователей, например), и расшифровывает-зашифровает тоже он.
Соответственно, менеджер никогда сам ничего расшифровать не сможет, а добавить или удалить менеджера из системы очень просто.
Т.е. блок зашифрованных данных состоит из, грубо говоря, зашифрованных 1 раз под 1 ключом «сессионный_ключ» данных, и набора из N пар (открытый_ключ_#N, сессионный_ключ_под_открытым_ключом_#N). Если надо подпись — аналогично добавляются подписи: M пар вида (открытый ключ подписи, зашифрованный на нем хэш данных). Нельзя умолчать о том, что ключ подписи не может быть равен ключу для шифрования, т.к. у них разглашаются (публикуются) разные части из ключевой пары.
Посмотрите, как это делается в стандарте PGP. Данные шифруются симметричным алгоритмом под случайным сеансовым ключом. Этот ключ шифруется под каждым открытом ключом. Соответственно, обладатель закрытой части какого-либюо из откртытых ключей сможет расшифровать сеансовый ключ и далее уже сами данные.
Да, они в даташите честно пишут, что на 44.1 кГц будет дрейф частоты, т.к. 44.1 кГц / 48 кГц ~= 147/160, и невозможно для 44.1 кГц равномерно перемешать 13 пустых фреймов со 147 нормальными из 160 для 48 кГц.
www.hardwaresecrets.com/datasheets/alc269.pdf Судя по даташиту на чип, да, умеет.
Тактовая частота, 24 МГц = значит, вполне влезет 192 К сэмплов по 24 бит.
Базовая частота сэмплинга — 48 кГц. Заявленные характеристики по шумам и проч. также измерялись на 48 кГц.
Я не меломан и не аудиофил ничуть, но все равно не стал бы на Вашем месте даже париться со встроенной звуковой картой, из-за плохого экранирования все Ваши успехи съедят дикие наводки уже после ЦАП (и в качестве которого на встроенных звуковухах также следует сомневаться).
Полностью согласен, что ПК на винде тут не лучший измерительный прибор.
Берем любой приличный цифровой осцилл с интерфейсом к ПК, вешаем на интересующие сигнальные линии и, используя его SDK и/или labview-плагин, делаем замеры.
Еще смотрите на gamedev.ru, там знают толк в таймерах: www.gamedev.ru/code/forum/?id=80205
Кажется, именно оттуда я копал пару лет назад, когда нужно было измерить именно на винде и именно с максимально высокой точностью
Надежность SRP-6 основывается на трудности задаче дискретного логарифмирования (DLP, discrete logarithm problem).
Если и на сервере, и на клиенте используются реализации протокола без явных уязвимостей, то грубые оценки по криптостойкости можно брать из Диффи-Хеллмана для той же длины модуля.
Еще кое-какие соображения по безопасности описаны в соотв. RFC (RFC 2945, RFC 5054).
Выбор хэш-функции важен, т.к. если злоумышленник скомпрометирует сервер аутентификации, то получение доступа к паролю можно свести к подбору хэша (словарь, rainbow-таблицы и вперед).
Вот здесь например, обсуждают стойкость конкретной реализации. Тут рассказывается, что будет, если взять короткий модуль и не самую стойкую хэш-функцию, с источниками.
А Вы пробовали читать/писать APIC-регистры до реаллоцирования, и какими способами?
Плюс я бы взглянул, какая (64-битная или 32-битная) инструкция по факту в бинарнике или в промежуточных ассемблерных сырцах (в Вашем makefile они не генерируются).
Желательно сделать отдельный сервер аутентификации и шифрования, на котором никаких веб-интерфейсов не будет и который зафаерволлен нафиг. А доступные из веб-морды сервисы аутентификации и шифрования на этом криптосервере только и умеют, что по максимально простым протоколам принимать пароли и данные, и отдавать флаг да/нет, данные зашифрованные/расшифрованные, и т.д.
К серверу аутентификации, в зависимости от масштабов задачи, можно подключать железные криптоускорители и токены/смарткарты с ключами к ним. На нем можно поднять полнодисковое шифрование, а ходить на него только по полужелезной консоли через IP-KVM от провайдера. Тогда угнать БД у Вас сможет только тот, кто имеет физический доступ к серверу (надеюсь, что удаленно эксплуатируемых через веб-морду уязвимостей в самих службах шифрования на выделенном криптосервере не будет).