Неплохо, неплохо

[jsn]

Меж тем, fallout от публикаций Сноудена в криптографии продолжает выпадать со страшной силой. Последнее из принесённого, на этот раз, Слэшдотом: после заявления Шнайера о том, что он теперь не доверяет шифрованию на эллиптических кривых, народ побежал вспоминать-искать, нет ли там чего-нибудь, похожего на закладку. И практически сразу же нашёл:

>> Bruce Schneier recommends *not* to use ECC. It is safe to assume he
>> knows what he says.
>
> I believe Schneier was being careless there. The ECC parameter sets
> commonly used on the internet (the NIST P-xxxr ones) were chosen using
> a published deterministically randomized procedure. I think the
> notion that these parameters could have been maliciously selected is a
> remarkable claim which demands remarkable evidence.

Okay, I need to eat my words here.

[...]

The deterministic procedure basically computes SHA1 on some seed and uses it to assign the parameters then checks the curve order, etc.. wash rinse repeat.

Then I looked at the random seed values for the P-xxxr curves. For example, P-256r's seed is c49d360886e704936a6678e1139d26b7819f7e90.

_No_ justification is given for that value. [...]

I now personally consider this to be smoking evidence that the parameters are cooked.

(original mailing list message)

Рекомендованные стандартом константы ECC изготовлены человеком NSA с помощью довольно подозрительного процесса. (Это не та же старая история про практически общеизвестную старую закладку NSA в Dual_EC_DRBG, это новое и гораздо круче). Дискуссия на соответствующем StackExchange:

The NIST FIPS 186-3 standard provides recommended parameters for curves that can be used for elliptic curve cryptography. These recommended parameters are widely used; it is widely presumed that they are a reasonable choice.

Тут сказано "широко используется". Насколько я понимаю, ECC-криптография вообще сильно менее "широко используется", чем DLP или IFP. Но вообще это big deal вроде бы -- один из трёх мейнстримовых математических фреймворков для шифрования с открытым ключом содержит палёные константы от NSA.

(оригинальный пост на Slashdot-е)

Comments

[rblaze.livejournal.com]

Это описание абсолютно соответствует тем процессам, по которым я пересекался с ФСБ и до того ФАПСИ :)

[jsn.livejournal.com]

О, а расскажи вообще, как там всё за железным занавесом устроено? Вот снаружи любой студент знает, что нельзя самому делать реализацию даже придуманного умными людьми крипто: ошибок налепишь, энтропию проебёшь, side channel-ов насажаешь, и т.д, и поэтому надо брать существующую реализацию с репутацией (e.g. openssl, nacl или что там), и использовать. Но в России-то, для сильно секретного, так нельзя, поди? Как же они живут? Вот это их ECC, например, как реализовано?

[rblaze.livejournal.com]

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

В России я лично накодировал [почти] все реализации криптоалгоритмов и протоколов, потому что готовых тупо нет, и то же самое сделали все остальные нуждающиеся в криптографии в нашей конторе. Количество допущеных при этом косяков представить себе сложно, с ходу я могу вспомнить парочку довольно грубых своих. Протоколы частично придуманы в ФАПСИ, частично нами, что из этого вышло... а хрен знает, я старался, но мало ли. Стойкость несколько усиливается тем, что никаких опций и закладок на разные реализации в этих протоколах нет, все взаимодействиующие устройства наши, шаг влево-вправо или не та версия - до свидания.

Всё это, разумеется, прошло сертификацию в ФСБ, и получило красивые бумажки с печатями. Сертификация заключалась в том, что проверялась правильность реализации заявленых алгоритмов, то бишь симметричного и асимметричного ГОСТа и программного ДСЧ. На протоколы смотрели разве что с точки зрения "а что это у вас на одном ключе все соединение шифруется, попилите его на кусочки по полтора килобайта и для каждого от исходного ключа сгенерируйте отдельный", да и то начиная с 2008 года, до того вообще на них не жаловались. Ни про какие ошибки типа padding oracle, правила authenticate then encrypt (или наоборот, whatever they want) и т.д. от сертификаторов я отродясь не слышал. Зато были запросы "а пропатчили ли вы такую-то ошибку в OpenSSL" и "у нас тут static analyzer на strlen ругается, исправьте".

При этом сертификационную лабораторию, которая возьмется за проект на базе FreeBSD, мы задолбались искать настолько, что собрались уж было перевести его на Linux. На тот момент не понадобилось, к счастью. Найти кого-то, способного проанализировать код не на C/C++, наверное невозможно вообще.