Протокол ЕКЕ страдает одним серьезным недостатком: он требует, чтобы обе стороны знали Р. В большинстве систем авторизации доступа хранятся значения однонаправленной хэш-функции паролей пользователей, а не сами пароли (см. раздел 3.2). Протокол Расширенный ЕКЕ (Augmented EKE, A-EKE) использует в варианте ЕКЕ на базе Diffie-Hellman значение однонаправленной хэш-функции пароля пользователя в качестве ключа сверхшифрования. Затем пользователь посылает дополнительное сообщение, основанное на реальном пароле, это сообщение удостоверяет заново выбранный сеансовый ключ .
Вот как это работает. Как и обычно, Алиса и Боб хотят проверить подлинность друг друга и генерировать общий ключ. Они выбирают какую-нибудь схему цифровой подписи, в которой в качестве закрытого ключа может использоваться любое число, а открытый ключ получается из закрытого, а не генерируется отдельно . Прекрасно подходят алгоритмы ElGamal и DSA. Пароль Алисы Р (или, может быть, какое-нибудь простое хэш-значение этого пароля) будет использоваться в качестве закрытого ключа и как Р'.
(1) Алиса выбирает случайный показатель степени Ra и отправляет EP{gr° mod и)
(2) Боб, который знает только Р' и не может получить из него Р, выбирает Rt и посылает Epigr" mod и)
(3) Алиса и Боб вычисляют общий сеансовый ключ К= g^% mod п. Наконец Алиса доказывает, что она сама знает Р, а не только Р', посылая
Eg{Sp{K))
Боб, который знает К и Р', может расшифровать и проверить подпись. Только Алиса могла прислать это сообщение, так как только она знает Р. Самозванец, добывший копию файла паролей Боба, может попытаться Р, но он не сможет подписать сеансовый ключ.
Схема А-ЕКЕ не работает с вариантом ЕКЕ, использующим открытые ключи, так как в этом протоколе одна сторона выбирает сеансовый ключ и навязывает его другой. Это позволяет взломщику, заполучившему Р', выполнить вскрытие "человек в середине".