MAC функция принимает на входе ключ и сообщение. На выходе выдаёт аутентификационный тэг или который тоже называют MAC-ом (как хэш-функция выдаёт хэш). Заявленный отправитель проверяет тем фактом, что ключ от MAC согласуется на этапе handshake только между двумя участниками сессии. Ключ этот знают только двое. Без MAC-а любое шифрование становится просто бесполезным, так как, особенно в потоковых шифрах, сообщение можно изменить и подделать не проводя дешифровку.Касательно ChaCha20 (да и любого потокового шифра, как например AES-CTR который тоже потоковый). Ключ применяется для выработки псевдослучайной последовательности. Грубо говоря, потоковый шифр это PRNG (генератор псевдослучайных чисел) на вход которому подаётся ключ, а на выходе выплёвывается длинная псевдослучайная строка. Эта строка просто XOR-ится с данными и результатом будет шифротекст. Из-за особенностей XOR-а, чтобы расшифровать её, то нужно снова сXOR-ить с этой PRNG последовательностью.
curve25519 -- очень быстрая, безопасная (http://safecurves.cr.yp.to/), проще многих других в реализации.
Асимметричного шифрования, шифрования как такового, не появляется вообще. Именно шифровать асимметрично уже давно перестали за ненадобностью. Из асимметричных примитивов используются: согласование ключей (Диффи-Хельман) и подпись. Без подписи нельзя аутентифицировать противоположную сторону: подписью (с предоставлением сертификата (публичный ключ подписанный третьей доверенной стороной)) оборачивается весь handshake где согласуются симметричные ключи, которые уже шифруют и MAC-аутентифицируют. DH используется для выработки этих симметричных ключей. Вообще именно DH стал первой на практике используемым асимметричным алгоритмом.
Всё очень просто. Каждое сообщение нам нужно зашифровать и аутентифицировать. Значит нужен шифр и MAC. Берём AES-CTR и HMAC, или ChaCha20 и Poly1305, или AES в GCM режиме (и шифр и MAC одновременно) или AES в CCM режиме (тоже шифр и MAC одновременно). Для этих двух функций нам нужны ключи, симметричные. И удалённой стороне нужны точно такие же. Значит нужен протокол согласования ключей, key agreement или, как это стало нарицательным, Диффи-Хельман, DH. Но DH уязвим к MitM атаке, где мы понятия не имеем что говорим именно со Сбербанком, а не с третьим лицом по-середине. Поэтому нужно (асимметрично) аутентифицировать противоположную сторону и в TLS используется инфраструктура публичных ключей (PKI) где у каждого есть сертификат (публичный ключ) подписанный доверенной третьей стороной. Сообщения DH просто подписываются приватным ключом этого сертификата противоположной стороны. Имеем: подтверждение (через третье лицо) что обмен handshake данными идёт со Сбербанком, согласование симметричных ключей, шифрование и аутентификация. Асимметричное шифрование банально просто не нужно чтобы point-to-point устанавливать зашифрованный/аутентифицированный канал связи.
curve25519 это Диффи-Хельман, а Ed25519 это подпись. Внутри по сути используется такая же кривая (быстрая, безопасная, итд) и поэтому "25519" однокоренное.
