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

Протокол безопасного удаленного пароля ( 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 [ править ]

""" 
 Пример аутентификации SRP 

 ПРЕДУПРЕЖДЕНИЕ. Не используйте для реальных криптографических целей, помимо тестирования. 
 ПРЕДУПРЕЖДЕНИЕ. В приведенном ниже коде отсутствуют важные меры безопасности. Он не проверяет, что A, B и U не равны нулю. 

 На основе http://srp. stanford.edu/design.html 
 """ 
 import   hashlib 
 import   random 

 # Примечание: str преобразуется как есть, str([1,2,3,4]) преобразуется в "[1,2,3,4]" 
 def   H  (  *  args  )   ->   int  : 
     """Односторонняя хэш-функция.""" 
     a   =   ":"  .   join  (  str  (  a  )   for   a   in   args  ) 
     return   int  (  hashlib.sha256  :  .hexdigest  (  a.encode  (  utf  "  -8"  )  )  (  ),   16  ) 

 def   cryptrand  (  n  int   )   =   1024  : 
     return   random  .   Системный случайный  ()  .   getrandbits  (  n  )   %   N 

 # Большое безопасное простое число (N = 2q+1, где q — простое число) 
 # Вся арифметика выполняется по модулю N 
 # (сгенерировано с использованием "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  replace  (  N  .split  (  ))  .  =  (  ":"  ,   ""  ),   16  ) 
 g   =   2    # Генератор по модулю N 

 k   =   H  (  N  ,   g  )   # Параметр множителя (k  3 в устаревшем SRP-6) 

 F   =   '#0x'   # Спецификатор формата 

 print  (  "#. H, N, g и k заранее известны как клиенту, так и серверу:"  ) 
 print  (  f  '  {  H   = }  \n  {  N   = :{  F  }}  \n  {  g   = :{  F  }}  \n  {  k   = :{  F  }}  '  ) 

 print  (  "  \n  0. сервер хранит (I, s, v) в своей базе данных паролей "  ) 

 # Сервер должен сначала сгенерировать средство проверки пароля 
 I   =   "person"          # Имя пользователя 
 p   =   "password1234"    # Пароль 
 s   =   cryptrand  (  64  )     # Salt для пользователя 
 x   =   H  (  s  ,   I  ,   p  )        # Закрытый ключ 
 v   =   pow  (  g  ,   x  ,   N  )      # Проверка пароля 

 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  (  "  \n  1. клиент отправляет на сервер имя пользователя I и общедоступное эфемерное значение A"  ) 
 a   =   cryptrand  () 
 A   =   pow  (  g  ,   a  ,   N  ) 
 print  (  f  "  {  I   = }  \n  {  A   = :{  F  }}  "  )    # клиент->сервер (I, A) 

 # 1. клиент отправляет имя пользователя I и общедоступное эфемерное значение A на сервер 
 # I = 'person' 
 # A = 0x678556a7e76581e051af656e8cee57ae46df43f1fce790f7750a3ec5308a85da4ec4051e5cb74d3e463685ee975a2747cf49035be67c931b56e793f23ea3524af8909dcfbc8675d872361025bf884778587ac49454a57c53a011ac2be2839bfb51bf7847a49a483aba870dc7a8b467a81cec91b8ae7813 

 # <demo> --- stop --- 

 print  (  "  \n  2. 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. сервер отправляет соль пользователя s и общедоступное эфемерное значение B для клиента 
 # s = 0x67bc8932cfd26a49 
 # B = 0xb615a0a5ea6abf138077bbd869f6a8da37dfc0b7e06a9f5fac5c1e4109c6302cb3e94dcc2cc76da7b3d87d7e9b68a 1db998ab239cfde609f3f7a1ece4a491ce3d9a665c20cf4e4f06730daaa8f52ed61 e45bbb67cdc337bf648027ffa7f0f215d5ebe43f9f51832518f1142266aae0dfa96 0e0082b5154 


# <demo> --- stop --- 

 print  (  "  \n  3. клиент и сервер вычисляют случайный параметр скремблирования"  ) 
 u   =   H  (  A  ,   B  )    # Случайный параметр скремблирования 
 print  (  f  "  {  u   = :{  F  }}  "  ) 

 # 3. клиент и сервер вычисляют случайный параметр скремблирования 
 # u = 0x796b07e354c04f672af8b76a46560655086355a9bbce11361f01b45d991c0c52 

 # <demo> --- stop --- 

 print  (  "  \n  4. клиент вычисляет сеансовый ключ"  ) 
 x   =   H  (  s  ,   I  ,   p  ) 
 S_c   =   pow  (  B   -   k   *   pow  (  g  ,   x  ,   N  ),   a   +   u   *   x  ,   N  ) 
 K_c   =   H  (  S_c  ) 
 печать  (  f  "  {  S_c   = :{  F  }}  \ n  {  K_c   = :{  F  }}  "  ) 

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

 # <demo> --- stop --- 

 print  (  "  \n  5. 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. сервер вычисляет сеансовый ключ 
 # S_s = 0x699170aff6e9f08ed09a1dff432bf0605b8bcba05aadcaeea665757d06dbda4348e211d16c10ef4678585bcb2809a83c62b6c19d97901274ddafd4075 f90604c06baf036af587af8540342b47867eaa22b9ca5e35ac14c8e85a0c4e623bd855828dffd513cea4d829c407137a0dd81ab4cde8a904c45cc 
# K_s = 0x43f8df6e1d2ba762948c8316db5bf03a7af49391742f5f5f51029630711c1671e 

 # <demo> --- stop --- 

 print  (  "  \n  6. клиент отправляет серверу подтверждение сеансового ключа"  ) 
 M_c   =   H  (  H  (  N  )   ^   H  (  g  ),   H  (  I  ) ,   s  ,   A  ,   B  ,   K_c  ) 
 print  (  f  "  {  M_c   = :{  F  }}  "  ) 
 # клиент->сервер (M_c);   сервер проверяет M_c 

 # 6. клиент отправляет подтверждение сеансового ключа на сервер 
 # M_c = 0x75500df4ea36e06406ac1f8a8241429b8e90a8cba3adda3405c07f19ea3101e8 

 # <demo> --- stop --- 

 print  (  "  \n  7. сервер отправляет клиенту подтверждение сеансового ключа"  ) 
 M_s   =   H  (  A  ,   M_c  ,   K_s  ) 
 print  (  f  "  {  M_s   = :{  F  }}  "  ) 
 # сервер->клиент (M_s);   клиент проверяет M_s 

 # 7. сервер отправляет клиенту подтверждение сеансового ключа 
 # M_s = 0x182ed24d1ad2fb55d2268c46b42435d1ef02e0fc49f647c03dab8b2a48b0bd3d

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

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

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

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

Кэрол → Стив: сгенерировать случайное значение a ; отправь $I$ и A = g ^а
Стив: $ты = Ч (А, Б); S = Av в; К знак равно ЧАС (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 октября 2023 г.
^ 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 октября 2023 г.

[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]