>> а если исходник — то так. точнее, почти так.
> Во первых, есть несколько реализаций с "одинаковым API".ты прямо написал NaCl.
> 1) NaCl - непосредственно от дяденьки Берштейна. Там таки несколько разных алгоритмов
> в ряде вызовов возможны. Например, crypto_hash() может использовать 2 алгоритма, etc.
поэтому я и сказал «почти». чтобы увидеть «рекомендованый минимум» — как раз TweetNaCl можно взять, там ровно по одному методу на рыло.
>>> И как раз аудит этого кода делался сильно меньшим количеством народа.
>> PolarSSL достаточно мелкая для того, чтобы можно было проаудитить самостоятельно.
> Скажем прямо, я не испытываю желания самостоятельно аудитить ни одну реализацию TLS
> вообще.
тогда молись, постись и всё такое. потому что это использовали и использовать будут ещё долго.
> Хороший пример - CurveCP.
плохой пример. оно, конечно, получше и попроще, но с багами в спеках. которые djb чинить не хочет. например, там возможно послать сообщение без данных, но невозможно сделать ему ACK. соответственно, при установке соединения клиент или сразу должен посылать что-то бесполезное, или бомбить сервер initiate-пакетами, надеясь на то, что оттуда придёт ACK по id'у (хотя в ответе поле lastid вообще не предназначено для ACK-ов, и если по нему убирать пакеты — чикага немного сходит с ума).
также там не предусмотрены простейшие keep-alive пакеты (то есть, их опять можно сделать только безжалостными хаками, чтобы не поломать совместимость с другими реализациями). а для UDP через NAT это иногда весьма полезно, иначе порт может закрыться.
CurveCP — это такая академическая игрушка, proof-of-concept.
> В таких вещах и апликушникам сложно лохануться
да, как я написал — достаточно облажаться авторам спеков. ;-)
