Протокол безопасного удаленного пароля

Протокол безопасного удаленного пароля ( SRP ) — это расширенный протокол обмена ключами с аутентификацией по паролю (PAKE), специально разработанный для обхода существующих патентов. ^[1]

Как и во всех протоколах PAKE, перехватчик или посредник не могут получить достаточно информации, чтобы иметь возможность методом перебора подобрать пароль или применить атаку по словарю без дальнейшего взаимодействия со сторонами для каждого предположения. Более того, поскольку сервер является расширенным протоколом PAKE, он не хранит данные, эквивалентные паролю. ^[2] Это означает, что злоумышленник, похитивший данные сервера, не сможет замаскироваться под клиента, если сначала он не выполнит перебор пароля.

С точки зрения непрофессионала, во время аутентификации SRP (или любого другого протокола PAKE) одна сторона («клиент» или «пользователь») демонстрирует другой стороне («серверу»), что она знает пароль, не отправляя ни сам пароль, ни какие-либо другая информация, из которой можно получить пароль. Пароль никогда не покидает клиент и неизвестен серверу.

Более того, серверу также необходимо знать пароль (но не сам пароль), чтобы установить безопасное соединение. Это означает, что сервер также аутентифицирует себя на клиенте, что предотвращает фишинг , не полагаясь на то, что пользователь анализирует сложные URL-адреса.

Единственным математически доказанным свойством безопасности SRP является то, что он эквивалентен методу Диффи-Хеллмана против пассивного злоумышленника. ^[3] Новые PAKE, такие как AuCPace ^[4] и OPAQUE предлагают более сильные гарантии. ^[5]

Обзор [ править ]

Протокол SRP обладает рядом желательных свойств: он позволяет пользователю аутентифицировать себя на сервере, он устойчив к словарным атакам, организованным перехватчиком, и не требует доверенной третьей стороны . Он эффективно передает подтверждение пароля с нулевым разглашением от пользователя на сервер. В версии 6 протокола за одну попытку подключения можно подобрать только один пароль. Одним из интересных свойств протокола является то, что даже если один или два используемых им криптографических примитива подвергаются атаке, он все равно остается безопасным. Протокол SRP несколько раз пересматривался и в настоящее время имеет версию 6a.

Протокол SRP создает большой закрытый ключ, общий для двух сторон, аналогично обмену ключами Диффи-Хеллмана, основанный на том, что на стороне клиента имеется пароль пользователя, а на стороне сервера имеется криптографический верификатор, полученный на основе пароля. Общий открытый ключ получается из двух случайных чисел, одно из которых генерируется клиентом, а другое — сервером, которые уникальны для попытки входа в систему. В случаях, когда требуется зашифрованная связь, а также аутентификация, протокол SRP более безопасен, чем альтернативный протокол SSH , и быстрее, чем использование обмена ключами Диффи-Хеллмана с подписанными сообщениями. Он также независим от третьих сторон, в отличие от Kerberos .

Протокол SRP версии 3 описан в RFC 2945. SRP версии 6a также используется для аутентификации с использованием надежного пароля в SSL/TLS. ^[6] (в TLS-SRP ) и других стандартах, таких как EAP. ^[7] и SAML и является частью IEEE 1363.2 и ISO/IEC 11770-4.

Протокол [ править ]

В данном описании протокола версии 6 используются следующие обозначения:

q и N = 2 q + 1 выбираются так, чтобы оба были простыми (что делает q простым числом Софи Жермен , а N безопасным простым числом ). N должно быть достаточно большим, чтобы вычисление дискретных логарифмов по модулю N было невозможным.
Вся арифметика выполняется в кольце целых чисел по модулю N , $\scriptstyle \mathbb {Z} _{N}$ . Это означает, что ниже g ^х следует читать как г ^хпротив Н
g — генератор мультипликативной группы $\scriptstyle \mathbb {Z} _{N}^{*}$ .
H () — хеш -функция; например, SHA-256.
k — параметр, получаемый обеими сторонами; в SRP-6 k = 3, а в SRP-6a оно получается из N и g : k = H ( N , g ). Он используется для предотвращения предположения 2 к 1, когда активный злоумышленник выдает себя за сервер. ^[8]^[9]
s — соль .
$Я$ — идентифицирующее имя пользователя.
p — пароль пользователя.
v — средство проверки пароля хоста, v = g ^х где как минимум x = H ( s , p ). Поскольку x вычисляется только на клиенте, можно выбрать более сильный алгоритм. Реализация может использовать $x = H (s | I | p),$ не затрагивая никаких шагов, требуемых от хоста. Стандарт RFC2945 определяет $x = H (s | H (I | ":" | p))$ . Использование $I$ внутри x не позволяет злонамеренному серверу узнать, используют ли два пользователя один и тот же пароль .
A и B — случайные одноразовые эфемерные ключи пользователя и хоста соответственно.
| (труба) обозначает конкатенацию.

Все остальные переменные определяются через них.

Во-первых, чтобы установить пароль p с сервером Стивом, клиент Кэрол выбирает случайную соль s и вычисляет x = H ( s , p ), v = g. ^х. Стив хранит v и s , индексированные $I$ , как средство проверки пароля и соль Кэрол. Кэрол не должна передавать x никому и должна безопасно удалить его на этом этапе, поскольку он эквивалентен открытому паролю p . Этот шаг выполняется до того, как система будет использоваться в рамках регистрации пользователя у Стива. Обратите внимание, что соль s является общей и обменивается для согласования сеансового ключа позже, поэтому значение может быть выбрано любой стороной, но это делает Кэрол, чтобы она могла зарегистрировать $I$ , s и v в одном запросе на регистрацию. Передача и аутентификация запроса на регистрацию не предусмотрены SRP.

Затем, чтобы выполнить подтверждение пароля позднее, используется следующий протокол обмена:

Кэрол → Стив: сгенерировать случайное значение a ; отправь $I$ и A = g ^а
Стив → Кэрол: сгенерировать случайное значение b ; отправить s и B = kv + g ^б
Оба: ты знак равно ЧАС ( А , B )
Кэрол: S _Кэрол = ( B − кг ^х) ^{( а + укс )} = ( kv + g ^б − кг ^х) ^{( а + укс )} = ( кг ^х − кг ^х + г ^б) ^{(а + ух)} = ( г ^б) ^{( а + укс )}
Кэрол: K _Кэрол = H ( S _Кэрол )
Стив: S _Стив = ( Выкл. ^в) ^б = ( г ^аv ^в) ^б = [ г ^а( г ^х) ^в] ^б = ( г ^{а + укс}) ^б = ( г ^б) ^{(а + ух)}
Стив: K _Стив = H ( S _Стив ) = K _Кэрол

Теперь у двух сторон есть общий надежный сеансовый K. ключ Для завершения аутентификации им необходимо доказать друг другу, что их ключи совпадают. Один из возможных способов заключается в следующем:

Кэрол → Стив: $M 1 знак равно ЧАС [ЧАС (N) XOR ЧАС (г) | Ч (я) | s | А | Б | К. Кэрол]$ . Стив проверяет М ₁ .
Стив → Кэрол: $M 2 = H (A | M 1 | K Стив)$ . Кэрол проверяет М ₂ .

Для успешного олицетворения этот метод требует угадывания большего количества общего состояния, чем только ключа. Хотя большая часть дополнительного состояния является общедоступной, личную информацию можно безопасно добавлять к входным данным хэш-функции, например, закрытый ключ сервера. ^{[ нужны разъяснения ]}

Альтернативно, при проверке только паролем вычисление K можно пропустить и доказать общее S с помощью:

Кэрол → Стив: $M 1 знак равно Ч (A | B | S Кэрол)$ . Стив проверяет М ₁ .
Стив → Кэрол: $M 2 = H (A | M 1 | S Стив)$ . Кэрол проверяет М ₂ .

использовании SRP для согласования общего ключа K который будет использоваться сразу после согласования, возникает соблазн пропустить этапы проверки M1 _и , M2 _При . Сервер отклонит самый первый запрос от клиента, который он не сможет расшифровать. Однако это может быть опасно, как показано в разделе «Подводные камни реализации» ниже.

Обе стороны также используют следующие гарантии:

Кэрол прервет выполнение, если получит B = 0 (mod N ) или u = 0.
Стив прервет выполнение, если получит A (mod N ) = 0.
Кэрол должна сначала показать свое доказательство K (или S ). Если Стив обнаружит, что доказательство Кэрол неверно, он должен прервать работу, не показывая собственное доказательство K (или S ).

Пример кода на Python [ править ]

"""
An example SRP authentication

WARNING: Do not use for real cryptographic purposes beyond testing.
WARNING: This below code misses important safeguards. It does not check A, B, and U are not zero.

based on http://srp.stanford.edu/design.html
"""
import hashlib
import random

# Note: str converts as is, str([1,2,3,4]) will convert to "[1,2,3,4]"
def H(*args) -> int:
    """A one-way hash function."""
    a = ":".join(str(a) for a in args)
    return int(hashlib.sha256(a.encode("utf-8")).hexdigest(), 16)

def cryptrand(n: int = 1024):
    return random.SystemRandom().getrandbits(n) % N

# A large safe prime (N = 2q+1, where q is prime)
# All arithmetic is done modulo N
# (generated using "openssl dhparam -text 1024")
N = """00:c0:37:c3:75:88:b4:32:98:87:e6:1c:2d:a3:32:
       4b:1b:a4:b8:1a:63:f9:74:8f:ed:2d:8a:41:0c:2f:
       c2:1b:12:32:f0:d3:bf:a0:24:27:6c:fd:88:44:81:
       97:aa:e4:86:a6:3b:fc:a7:b8:bf:77:54:df:b3:27:
       c7:20:1f:6f:d1:7f:d7:fd:74:15:8b:d3:1c:e7:72:
       c9:f5:f8:ab:58:45:48:a9:9a:75:9b:5a:2c:05:32:
       16:2b:7b:62:18:e8:f1:42:bc:e2:c3:0d:77:84:68:
       9a:48:3e:09:5e:70:16:18:43:79:13:a8:c3:9c:3d:
       d0:d4:ca:3c:50:0b:88:5f:e3"""
     
N = int("".join(N.split()).replace(":", ""), 16)
g = 2  # A generator modulo N

k = H(N, g) # Multiplier parameter (k=3 in legacy SRP-6)

F = '#0x' # Format specifier

print("#. H, N, g, and k are known beforehand to both client and server:")
print(f'{H = }\n{N = :{F}}\n{g = :{F}}\n{k = :{F}}')

print("\n0. server stores (I, s, v) in its password database")

# The server must first generate the password verifier
I = "person"        # Username
p = "password1234"  # Password
s = cryptrand(64)   # Salt for the user
x = H(s, I, p)      # Private key
v = pow(g, x, N)    # Password verifier

print(f'{I = }\n{p = }\n{s = :{F}}\n{x = :{F}}\n{v = :{F}}')

# 0. server stores(I, s, v) in its password database
# I = 'person'
# p = 'password1234'
# s = 0x67bc8932cfd26a49
# x = 0x98a4bce8dde877762a90222f1a1161eba9248590a47eb83aa9e5bd7ecda5368d
# v = 0xa7e2038e675d577ac0f318999cab67bba7ec2daf45d2d09f7911b1b78d2fc7f963cd0ac8f17851e0516f059e453672c3b70fcecf5f6843180b271abdd01f552ccda7b24fe4719336409cbc1352f8517be651b8935cc0b74ff2819fa07a3f031537d4cfd9f8df7b788a5f2f88e1cd4106b35c38b3d7205a

# <demo> --- stop ---

print("\n1. client sends username I and public ephemeral value A to the server")
a = cryptrand()
A = pow(g, a, N)
print(f"{I = }\n{A = :{F}}")  # client->server (I, A)

# 1. client sends username I and public ephemeral value A to the server
# I = 'person'
# A = 0x678556a7e76581e051af656e8cee57ae46df43f1fce790f7750a3ec5308a85da4ec4051e5cb74d3e463685ee975a2747cf49035be67c931b56e793f23ea3524af8909dcfbc8675d872361025bf884778587ac49454a57c53a011ac2be2839bfb51bf7847a49a483aba870dc7a8b467a81cec91b8ae7813

# <demo> --- stop ---

print("\n2. server sends user's salt s and public ephemeral value B to client")
b = cryptrand()
B = (k * v + pow(g, b, N)) % N
print(f"{s = :{F}}\n{B = :{F}}")  # server->client (s, B)

# 2. server sends user's salt s and public ephemeral value B to client
# s = 0x67bc8932cfd26a49
# B = 0xb615a0a5ea6abf138077bbd869f6a8da37dfc0b7e06a9f5fac5c1e4109c6302cb3e94dcc2cc76da7b3d87d7e9b68a1db998ab239cfde609f3f7a1ece4a491ce3d9a665c20cf4e4f06730daaa8f52ed61e45bbb67cdc337bf648027ffa7f0f215d5ebe43f9f51832518f1142266aae0dfa960e0082b5154


# <demo> --- stop ---

print("\n3. client and server calculate the random scrambling parameter")
u = H(A, B)  # Random scrambling parameter
print(f"{u = :{F}}")

# 3. client and server calculate the random scrambling parameter
# u = 0x796b07e354c04f672af8b76a46560655086355a9bbce11361f01b45d991c0c52

# <demo> --- stop ---

print("\n4. client computes session key")
x = H(s, I, p)
S_c = pow(B - k * pow(g, x, N), a + u * x, N)
K_c = H(S_c)
print(f"{S_c = :{F}}\n{K_c = :{F}}")

# 4. client computes session key
# S_c = 0x699170aff6e9f08ed09a1dff432bf0605b8bcba05aadcaeea665757d06dbda4348e211d16c10ef4678585bcb2809a83c62b6c19d97901274ddafd4075f90604c06baf036af587af8540342b47867eaa22b9ca5e35ac14c8e85a0c4e623bd855828dffd513cea4d829c407137a0dd81ab4cde8a904c45cc
# K_c = 0x43f8df6e1d2ba762948c8316db5bf03a7af49391742f5f51029630711c1671e

# <demo> --- stop ---

print("\n5. server computes session key")
S_s = pow(A * pow(v, u, N), b, N)
K_s = H(S_s)
print(f"{S_s = :{F}}\n{K_s = :{F}}")

# 5. server computes session key
# S_s = 0x699170aff6e9f08ed09a1dff432bf0605b8bcba05aadcaeea665757d06dbda4348e211d16c10ef4678585bcb2809a83c62b6c19d97901274ddafd4075f90604c06baf036af587af8540342b47867eaa22b9ca5e35ac14c8e85a0c4e623bd855828dffd513cea4d829c407137a0dd81ab4cde8a904c45cc
# K_s = 0x43f8df6e1d2ba762948c8316db5bf03a7af49391742f5f51029630711c1671e

# <demo> --- stop ---

print("\n6. client sends proof of session key to server")
M_c = H(H(N) ^ H(g), H(I), s, A, B, K_c)
print(f"{M_c = :{F}}")
# client->server (M_c) ; server verifies M_c

# 6. client sends proof of session key to server
# M_c = 0x75500df4ea36e06406ac1f8a8241429b8e90a8cba3adda3405c07f19ea3101e8

# <demo> --- stop ---

print("\n7. server sends proof of session key to client")
M_s = H(A, M_c, K_s)
print(f"{M_s = :{F}}")
# server->client (M_s) ;  client verifies M_s

# 7. server sends proof of session key to client
# M_s = 0x182ed24d1ad2fb55d2268c46b42435d1ef02e0fc49f647c03dab8b2a48b0bd3d

Подводные камни реализации [ править ]

с отправкой сообщений на сервер при отсутствии проверки Офлайн-атака методом перебора ключа

Если сервер отправляет зашифрованное сообщение, не дожидаясь проверки от клиента, злоумышленник может провести автономную атаку методом перебора, аналогичную взлому хеша. Это может произойти, если сервер отправляет зашифрованное сообщение во втором пакете вместе с солью и B или если проверка ключа пропущена и сервер (а не клиент) отправляет первое зашифрованное сообщение. поскольку после самого первого пакета сервер располагает всей информацией для вычисления общего ключа K. Это заманчиво ,

Атака происходит следующим образом:

Кэрол → Стив: сгенерировать случайное значение a ; отправь $I$ и A = g ^а
Стив: $ты = Ч (А, Б); S = Выкл. в; К знак равно ЧАС (S)$
Стив: сгенерировать сообщение m и зашифровать его, чтобы получить $c =ENC(K, m)$
Стив → Кэрол: сгенерировать случайное значение b ; отправить s , $B = kv + g б$ и с

Кэрол не знает x или v . Но, зная любой пароль p, она может вычислить:

$x p = H (соль, р)$
$S п = (B - кг х р) (а + ux р)$
$K п знак равно ЧАС (S п)$

K _p — это ключ, который Стив использовал бы, если бы p был ожидаемым паролем. Все значения, необходимые для вычисления K _p, либо контролируются Кэрол, либо известны из первого пакета от Стива. Теперь Кэрол может попытаться угадать пароль, сгенерировать соответствующий ключ и попытаться расшифровать зашифрованное сообщение Стива c , чтобы проверить ключ. Поскольку сообщения протокола имеют тенденцию быть структурированными, предполагается, что определить, что c был правильно расшифрован, легко. Это позволяет восстановить пароль в автономном режиме.

Эта атака была бы невозможна, если бы Стив ждал, пока Кэрол докажет, что она способна вычислить правильный ключ, прежде чем отправлять зашифрованное сообщение. Эта атака не затрагивает правильную реализацию SRP, поскольку злоумышленник не сможет пройти этап проверки ключа.

Оффлайн-брутфорс на основе тайм - атаки

В 2021 году Даниэль Де Алмейда Брага, Пьер-Ален Фук и Мохамед Сабт опубликовали книгу «ПАРАЗИТ». ^[10] статья, в которой они демонстрируют практическое использование временной атаки в сети. Это использует непостоянные реализации модульного возведения в степень больших чисел и особенно влияет на OpenSSL.

Реализации [ править ]

Переменные SRP-6 Библиотека Java криптографических примитивов, необходимая для реализации протокола SRP-6.
OpenSSL версии 1.0.1 или новее.
Botan (криптобиблиотека C++) содержит реализацию SRP-6a.
TLS-SRP — это набор наборов шифров для безопасности транспортного уровня , использующий SRP.
srp-client Реализация SRP-6a на JavaScript (совместима с RFC 5054), с открытым исходным кодом, под лицензией Mozilla Public License (MPL).
Криптобиблиотека JavaScript включает в себя реализацию протокола SRP на языке JavaScript с открытым исходным кодом и лицензией BSD .
Gnu Crypto предоставляет реализацию Java под лицензией GNU General Public License с «библиотечным исключением», которое разрешает ее использование в качестве библиотеки в сочетании с несвободным программным обеспечением.
Legion of the Bouncy Castle предоставляет Java и C# реализации по лицензии MIT .
Nimbus SRP — это библиотека Java, предоставляющая генератор верификаторов, сеансы на стороне клиента и сервера. Включает интерфейсы для настраиваемого ключа пароля, процедур сообщения доказательств клиента и сервера. Никаких внешних зависимостей. Выпущено под лицензией Apache 2.0 .
srplibcpp — это реализация C++ на базе MIRACL .
DragonSRP — это модульная реализация C++, которая в настоящее время работает с OpenSSL .
Json2Ldap обеспечивает аутентификацию SRP-6a для серверов каталогов LDAP .
csrp Реализация SRP-6a на C.
Crypt-SRP Реализация SRP-6a на Perl .
Реализация pysrp SRP-6a на Python (совместима с csrp ).
Реализация py3srp SRP-6a на чистом Python3 .
srptools Инструменты для реализации аутентификации по безопасному удаленному паролю (SRP) в Python . Проверенные совместимые библиотеки .
Meteor реализует SRP для аутентификации по паролю. Система учетных записей веб-платформы
srp-rb Реализация SRP-6a в Ruby .
falkmueller demo SRP-6a реализация Стэнфордского проекта протокола SRP на JavaScript и PHP под лицензией MIT .
srp-6a-demo Реализация SRP-6a на PHP и JavaScript .
Thinbus-srp-js Реализация SRP-6a на JavaScript . Поставляется с совместимыми классами Java , которые используют Nimbus SRP и демонстрационное приложение с использованием Spring Security . Существует также демонстрационное приложение, выполняющее аутентификацию на PHP- сервере. Выпущено под лицензией Apache .
Стэнфордская криптографическая библиотека JavaScript (SJCL) реализует SRP для обмена ключами.
node-srp — это клиентская и серверная реализация SRP на JavaScript (node.js).
SRP6 для реализации C# и Java на C# и Java.
ALOSRPAuth — это реализация SRP-6a на Objective-C.
go-srp — это реализация SRP-6a на Go.
tssrp6a — это реализация SRP-6a на TypeScript.
Java-библиотека TheIceNet Cryptography для разработки приложений Spring Boot на основе криптографии. Реализует SRP-6a. По лицензии Apache .
SRP-6a в .NET-реализации SRP-6a
Apple Homekit Apple Homekit использует SRP при сопряжении с аксессуарами и устройствами «умного» дома
Протонная аутентификация почты для шифрования электронной почты
SRP — это реализация SRP на Go, используемая для аутентификации пользователей в Posterity .

История [ править ]

Проект SRP стартовал в 1997 году. ^[11] Два разных подхода к устранению дыры в безопасности в SRP-1 привели к появлению SRP-2 и SRP-3. ^[12] SRP-3 был впервые опубликован в 1998 году на конференции. ^[13] RFC 2945, описывающий SRP-3 с SHA1, был опубликован в 2000 году. ^[14] SRP-6, исправляющий атаки угадывания и упорядочивания сообщений «два к одному», был опубликован в 2002 году. ^[8] SRP-6a появился в официальной «libsrp» в версии 2.1.0, датированной 2005 годом. ^[15] SRP-6a встречается в стандартах как:

ISO/IEC 11770-4:2006 «Механизм ключевого соглашения 2» (называет метод «SRP-6, но имеет k- расчет 6a)
RFC 5054 TLS-SRP 2007 г. (снова упоминается как «SRP-6», но исправлена опечатка). ^[16])
IEEE Std 1363.2-2008 «DLAPKAS-SRP6» (снова называемый «SRP-6») ^[17]

IEEE 1363.2 также включает описание «SRP5», варианта, заменяющего дискретный логарифм эллиптической кривой, предложенного Юнге Вангом в 2001 году. ^[18] Он также описывает SRP-3, содержащийся в RFC 2945.

См. также [ править ]

Ссылки [ править ]

^ «Что такое СРП?» . Стэнфордский университет .
^ Шерман, Алан Т.; Ланус, Эрин; Лисков, Моисей; Зиглар, Эдвард; Чанг, Ричард; Голашевский, Энис; Внук-Финк, Райан; Боньяди, Сайрус Дж.; Яксетиг, Марио (2020), Нигам, Вивек; Пан Киригин, Таяна; Талкотт, Кэролайн; Гуттман, Джошуа (ред.), «Анализ формальных методов протокола безопасного удаленного пароля», Логика, язык и безопасность: эссе, посвященные Андре Щедрову по случаю его 65-летия , Конспекты лекций по информатике, Cham: Springer International Издательство, стр. 103–126, arXiv : 2003.07421 , doi : 10.1007/978-3-030-62077-6_9 , ISBN. 978-3-030-62077-6
^ Грин, Мэтью (18 октября 2018 г.). «Следует ли вам использовать SRP?» . Несколько мыслей о криптографической инженерии . Примечание: источник называет SRP-6 SRPv4 по неизвестной причине.
^ Хаазе, Бьорн (22 января 2023 г.). «(strong) AuCPace, расширенный PAKE [draft-haase-aucpace-07]» . Рабочая группа по интернет-инжинирингу . Проверено 10 июня 2023 г.
^ Станислав Ярецкий; Хьюго Кравчик; Цзяюй Сюй. OPAQUE: асимметричный протокол PAKE, защищенный от атак с предварительным вычислением (PDF) . Еврокрипт 2018.
^ Тейлор, Дэвид; Том Ву; Никос Маврогианнопулос; Тревор Перрин (ноябрь 2007 г.). «Использование протокола безопасного удаленного пароля (SRP) для аутентификации TLS» . RFC 5054
^ Карлсон, Джеймс; Бернар Абоба; Генри Хаверинен (июль 2001 г.). «Протокол аутентификации EAP SRP-SHA1» . IETF. Черновик.
↑ Перейти обратно: Перейти обратно: ^а ^б Ву, Том (29 октября 2002 г.). SRP-6: Улучшения и уточнения протокола безопасного удаленного пароля (технический отчет).
^ «Проектирование протокола SRP» .
^ «ПАРАЗИТ: Атака с восстановлением пароля на реализации Srp в дикой природе» . Проверено 8 ноября 2023 г.
^ «СРП: О проекте» . srp.stanford.edu .
^ «СРП-2: Технические условия на проектирование» . srp.stanford.edu .
^ Ву, Т., « Протокол безопасного удаленного пароля », Труды симпозиума по безопасности сетей и распределенных систем Internet Society 1998 г., стр. 97-111, март 1998 г.
^ «СРП: Технические условия на проектирование» . srp.stanford.edu .
^ Файл ИЗМЕНЕНИЙ в srp-2.1.2.tar.gz, доступен по адресу http://srp.stanford.edu/download.html.
^ Ван, Мингье. «Отчет об ошибках RFC № 7538» . Редактор RFC . Получено 15 октября.
^ IEEE 1363.2-2008: Стандартная спецификация IEEE для методов шифрования с открытым ключом на основе пароля.
^ Ван, Ю., «Представление IEEE P1363.2 / D2001-06-21», [P1363.2-ecsrp-06-21.doc] Вклад Йонге Ванга для P1363.2, дающий версию SRP с эллиптической кривой. протокол от 21 июня 2001 г.

Внешние ссылки [ править ]

Официальный сайт
Лицензия SRP — BSD, аналогичный открытому исходному коду.
US6539479 — патент SRP (Срок действия истек 12 мая 2015 г. из-за неуплаты платы за обслуживание (согласно Google Patents). Первоначально срок действия истекал в июле 2018 г.).

Страницы руководства [ править ]

pppd(8) : демон протокола «точка-точка»
srptool(1) : Простой инструмент для паролей SRP.

RFC [ править ]

RFC 2944 — Аутентификация Telnet: SRP
RFC 2945 — Система аутентификации SRP и обмена ключами (версия 3)
RFC 3720 — Интерфейс малых компьютерных систем Интернета (iSCSI)
RFC 3723 — Защита протоколов блочного хранения данных через IP
RFC 3669 — Рекомендации для рабочих групп по вопросам интеллектуальной собственности
RFC 5054 — Использование протокола безопасного удаленного пароля (SRP) для аутентификации TLS

Другие ссылки [ править ]

ИЭЭЭ 1363
Слайды SRP по интеллектуальной собственности (декабрь 2001 г. – возможно, устарели) Срок действия упомянутых патентов EKE истек в 2011 и 2013 гг.

[1] «Что такое СРП?» . Стэнфордский университет .

[2] Шерман, Алан Т.; Ланус, Эрин; Лисков, Моисей; Зиглар, Эдвард; Чанг, Ричард; Голашевский, Энис; Внук-Финк, Райан; Боньяди, Сайрус Дж.; Яксетиг, Марио (2020), Нигам, Вивек; Пан Киригин, Таяна; Талкотт, Кэролайн; Гуттман, Джошуа (ред.), «Анализ формальных методов протокола безопасного удаленного пароля», Логика, язык и безопасность: эссе, посвященные Андре Щедрову по случаю его 65-летия , Конспекты лекций по информатике, Cham: Springer International Издательство, стр. 103–126, arXiv : 2003.07421 , doi : 10.1007/978-3-030-62077-6_9 , ISBN. 978-3-030-62077-6

[3] Грин, Мэтью (18 октября 2018 г.). «Следует ли вам использовать SRP?» . Несколько мыслей о криптографической инженерии . Примечание: источник называет SRP-6 SRPv4 по неизвестной причине.

[4] Хаазе, Бьорн (22 января 2023 г.). «(strong) AuCPace, расширенный PAKE [draft-haase-aucpace-07]» . Рабочая группа по интернет-инжинирингу . Проверено 10 июня 2023 г.

[5] Станислав Ярецкий; Хьюго Кравчик; Цзяюй Сюй. OPAQUE: асимметричный протокол PAKE, защищенный от атак с предварительным вычислением (PDF) . Еврокрипт 2018.

[6] Тейлор, Дэвид; Том Ву; Никос Маврогианнопулос; Тревор Перрин (ноябрь 2007 г.). «Использование протокола безопасного удаленного пароля (SRP) для аутентификации TLS» . RFC 5054

[7] Карлсон, Джеймс; Бернар Абоба; Генри Хаверинен (июль 2001 г.). «Протокол аутентификации EAP SRP-SHA1» . IETF. Черновик.

[srp6-8] Перейти обратно: Перейти обратно: ^а ^б Ву, Том (29 октября 2002 г.). SRP-6: Улучшения и уточнения протокола безопасного удаленного пароля (технический отчет).

[9] «Проектирование протокола SRP» .

[10] «ПАРАЗИТ: Атака с восстановлением пароля на реализации Srp в дикой природе» . Проверено 8 ноября 2023 г.

[11] «СРП: О проекте» . srp.stanford.edu .

[12] «СРП-2: Технические условия на проектирование» . srp.stanford.edu .

[13] Ву, Т., « Протокол безопасного удаленного пароля », Труды симпозиума по безопасности сетей и распределенных систем Internet Society 1998 г., стр. 97-111, март 1998 г.

[14] «СРП: Технические условия на проектирование» . srp.stanford.edu .

[15] Файл ИЗМЕНЕНИЙ в srp-2.1.2.tar.gz, доступен по адресу http://srp.stanford.edu/download.html.

[16] Ван, Мингье. «Отчет об ошибках RFC № 7538» . Редактор RFC . Получено 15 октября.

[17] IEEE 1363.2-2008: Стандартная спецификация IEEE для методов шифрования с открытым ключом на основе пароля.

[18] Ван, Ю., «Представление IEEE P1363.2 / D2001-06-21», [P1363.2-ecsrp-06-21.doc] Вклад Йонге Ванга для P1363.2, дающий версию SRP с эллиптической кривой. протокол от 21 июня 2001 г.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]