Talk:Secure Remote Password protocol

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as Low-importance).

Python Example Output

There seems to be an error in this output. I believe it is supposed to show the client and server generate the same session keys however they are clearly different lengths and looking closer you can see that there are some non hexadecimal values causing the difference. I am fairly sure this a bug in the code.

4. client computes session key S_c = 0x94ea4b72b61d4330hcf44f31e5c710491d41abdd6dd5b66b277bc5e17addbe89d9aa002645897567ae7796d1574f5d7f62cf96d2246adabfbc919alscf1444d69097ceaf5476bc3964cacd52697e346f5e5a424c2c89b661d2eba34e5c7195573442195611497f606fa49639f873f385d0f6cdb9308fe2b0777d1a89bbaebe9df237a4 K_c = 0x3f1e089e02b3770a5e4ab27b3a04415e54826fe4b729cd37b86fbe59b9e0d3c6

5. server computes session key S_s = 0x94ea4b72b61d4330ecf44f31e5c710491d41abdd6dd5b66b277bc517addbe89d9aa002645897567ae7796d1574f5d7f62cf96d2246daibfbc919cf1444d69097ceaf5476bc3964cacd52697en346f5e5a424c2c89b661d2eba34e5c719557344219t5611497f606fa49639f873f385d0f6cdb9308fe2b0777d1a89bbaebe9df237a4 K_s = 0x3f1e089e02b3770a5e4ab27b3a04415e54826fe4bg729cd37b86fbe59b9e0hd3c6 — Preceding unsigned comment added by 5.71.204.100 (talk) 17:55, 12 December 2017 (UTC)[reply]

Talk

Small nitpick: If $N=2q+1$ and both $N$ and $q$ are prime then $q$ (not $N$ ) is called a Sophie Germain prime. Unfortunately, this error calling the bigger prime "Sophie Germain" is quite popular in cryptography and even made it into some RFCs.

I have also noticed this and made the correction. TheAnarcat (talk) 22:07, 23 July 2009 (UTC)[reply]

Actually, before we make that change, we probably want to make some changes to the Safe_prime and Sophie_Germain_prime pages, as they agree with the original writing here (which i just reverted back to). TheAnarcat (talk) 22:24, 23 July 2009 (UTC)[reply]

g?

How generator of the multiplicative group is selected? Dipogogo (talk) 10:31, 22 July 2009 (UTC)[reply]

Python Code flaw

The example states that the chosen prime is a large, safe prime. 1024 bits are no longer long neither safe size for anything that is supposed to live longer than a month or three. — Preceding unsigned comment added by 80.252.219.34 (talk) 12:54, 21 January 2016 (UTC)[reply]

In the code there, it uses random.getrandbits, which is OK for demonstrative purposes. However, the random module documentation included a clear warning:

Almost all module functions depend on the basic function random(), which generates a random float uniformly in the semi-open range [0.0, 1.0). Python uses the Mersenne Twister as the core generator. It produces 53-bit precision floats and has a period of 2**19937-1. The underlying implementation in C is both fast and threadsafe. The Mersenne Twister is one of the most extensively tested random number generators in existence. However, being completely deterministic, it is not suitable for all purposes, and is completely unsuitable for cryptographic purposes.

(from Python v2.6.4 documentation, The Python Standard Library, 10. Numeric and Mathematical Modules, random)

A safer alternative for someone to use would be os.urandom, which relies on an OS implementation:

os.urandom(n) Return a string of n random bytes suitable for cryptographic use.

This function returns random bytes from an OS-specific randomness source. The returned data should be unpredictable enough for cryptographic applications, though its exact quality depends on the OS implementation. On a UNIX-like system this will query /dev/urandom, and on Windows it will use CryptGenRandom. If a randomness source is not found, NotImplementedError will be raised.

New in version 2.4.

(from Python v2.6.4 documentation, The Python Standard Library, 16. Generic Operating System Services, os, 16.1.7 Miscellaneous Functions)

I'm not going to change this, but it would be a good recommendation. —Preceding unsigned comment added by 70.100.231.253 (talk) 02:00, 12 August 2010 (UTC)[reply]

I've also noticed that the code performs modulo N on the generated random number. Timothy (talk) 22:50, 13 February 2011 (UTC)[reply]

Clarify section "Protocol"

I find a few things in the section "Protocol" unclear or improvable:

u isn't random, it's computed in step 3.
x is discarded only on Steve; Carol must remember x for step 4.
In step 4, why not write v in place of g^x as before?
Why does Steve transmit the salt s in step 2? Are we assuming that Carol did not store v?
How are N and g chosen and remembered?

Thanks! 82.35.49.111 (talk) 08:45, 13 February 2011 (UTC)[reply]

Actually, Carol must remember password, from which he can generate x.

In step 4, why not write v in place of g^x as before?

Is possible.

Why does Steve transmit the salt s in step 2? Are we assuming that Carol did not store v?

Nope. The only things Carol is storing are login and password.

How are N and g chosen and remembered?

They are parts of the protocol. — Preceding unsigned comment added by 77.4.152.254 (talk) 19:03, 14 August 2011 (UTC)[reply]

Confusing about arithmetic

What exactly meaning of "All arithmetic is performed in the field of integers modulo N"?

In python demonstration, It seem like only "power mod" operation in the field of modulo N. Others like additon, subtraction, multiplication are beyond the field. Should these operation module N too? — Preceding unsigned comment added by 58.38.19.167 (talk) 18:21, 3 October 2011 (UTC)[reply]

I agree, this point needs proper clarification 81.153.206.110 (talk) 11:48, 22 October 2011 (UTC)[reply]

Any operation should be modulo N. This is just python code flaw. 1.2.3.4 — Preceding unsigned comment added by 178.27.147.19 (talk) 01:26, 2 February 2012 (UTC)[reply]

Patents?

Why is there no mention of this the highly contentious IPR status of SRP? Did it become no longer highly contentious?--71.191.197.79 (talk) 05:52, 30 June 2011 (UTC)[reply]

[1]

SRP is available to commercial and non-commercial users under a royalty-free license. The Internet played a significant role in SRP's early development; without it, SRP would not have received anywhere near the amount of analysis and feedback that it has gotten since it was first proposed and refined. It is thus fitting that the Internet at large can benefit from the fruits of this endeavor. Since SRP is specifically designed to work around existing patents in the area, it gives everybody access to strong, unencumbered password authentication technology that can be put to a wide variety of uses.

Negative Problem

How does the protocol deal with issue of a negative result from S_c = pow(B - k * pow(g, x, N), a + u * x, N) specifically "B - k * pow(g, x, N)"81.153.206.110 (talk) 09:54, 22 October 2011 (UTC)[reply]

In the SRP protocol, all operations are done modulo N.

This Python implementation doesn't actually do the subtraction modulo N, but it gets the same results because the outer pow() is done modulo N.([2]).

If the subtraction gives a negative result R,

you could imagine that the outer pow() operator adds N to that result R enough times (perhaps z times) to get some positive number P = R+z*N, then it calculates S_c = pow( P, a + u * x ) % N = pow( R+z*N, a + u * x ) % N. (This always produces the same result S_c for every integer value of z).

(Internally the 3-argument pow() function actually uses a different, much faster algorithm to produce the same output positive integer S_c).

How could we change the article to make it easier to understand? --DavidCary (talk) 13:57, 8 February 2014 (UTC)[reply]

Secrets?

This article should make clear which parameters are public and which are secret to each party.--agr (talk) 10:47, 12 August 2012 (UTC)[reply]

Of permamently stored data:

Client only remembers login and password, so password should be the only secret

On server's side, salt and verifier together allow to bruteforce password, though slowly, and identify itself as server. Salt is public, so verifier should be kept private. — Preceding unsigned comment added by 94.216.41.167 (talk) 13:35, 15 August 2012 (UTC)[reply]

Ring or field?

question: 2nd bullet in "protocol says:

All arithmetic is performed in the ring of integers modulo N, $\scriptstyle \mathbb {Z} _{N}$ .

since N is prime, shouldn't this be "field" rather than "ring"? peace - קיפודנחש (aka kipod) (talk) 18:59, 21 April 2014 (UTC)[reply]

The SRP patent link

@SEPeltz: regarding this edit, as it stands, having this link would give readers the wrong impression, as if they can't freely use this protocol. The article does not mention the licensing situation at all, or that a patent has been granted. It would be much better covered in prose instead of just an external link.

Second, "The link IS the source" does not work, WP:PATENTS are not reliable sources. The patent may claim that it covers SRP, but there needs to be an independent reliable source supporting that claim to say it on Wikipedia. Otherwise, analysing the applicability of a patent is a complicated process and would be original research. -- intgr [talk] 09:20, 22 April 2015 (UTC)[reply]

-- The patent is by the creator of SRP, owned by Stanford, which licenses SRP (the link above the link I added). The patent says "The preferred embodiment of the password authentication method or protocol of the present invention will be called the Secure Remote Password protocol, or SRP, for the remainder of this document." What exactly the patent covers and whether the claims are valid is obviously not something that can be simply asserted, however stating that the patent itself IS the SRP patent is obvious and requires no further research than to simply look at the patent.

You are not allowed to freely use SRP, the license explicitly disallows using the SRP-Z form (where the server has an explicit secret). Such a requirement would not have any effect without the patent;

I added the link because it took me a while to find it, not having seen it listed in any of the references. If you think it requires more of an explanation in the article with references to the license, then by all means do so. See http://www.ietf.org/ietf-ftp/IPR/WU-SRP for a reference to it being patent-pending (in 2000, the patent issued in 2003). I simply wanted a reference to the patent itself.

I think there should also be a description of how SRP-Z would work (by using the generic definition of AKE as given in the SRP paper and patent and substituting the specified functions for SRP without setting z to 0), but since I've been unable to find anything regarding SRP-Z (the patent dismisses it after briefly describing it), I guess there's no way to make any reference to it. -- SEP (apologies for not knowing how to flag/tag/sign/ping/whatever) — Preceding unsigned comment added by SEPeltz (talk • contribs) 09:58, 22 April 2015 (UTC)[reply]

@SEPeltz: Interesting, the official websites/documents seem to go out of their way to avoid saying that there is a patent on the protocol, though they emphasize that they avoided prior patents and that SRP is available "royalty free".

But you're right, after searching around, it's quite clear that there is a patent on SRP and this is the right one. -- intgr [talk] 11:39, 22 April 2015 (UTC)[reply]

Layman explanation?

Could really use one or two sentences at beginning, in layman terms (assume knowledge of basic computer software terminology, but not of security terminology).

I didn't understand the purpose and benefit of SRP until I found a stackoverflow answer:

http://stackoverflow.com/a/4642699/199364

   Start with both parties already having agreed [to] a password.

Ahhh. Before reading this, I thought SRP was part of a secure mechanism for communicating the password in the first place; I did not realize it was an authentication mechanism for use after the password was known to both sides.

And a sentence in a comment to that stackover answer:

   The difficulty in dealing with passwords is how you avoid sending the password in plaintext on the wire, and that's one of the driving forces behind SRP.

That's exactly what I needed to know, to know "WHY use SRP?".

I will attempt to add a couple of sentences to beginning of intro. I apology for the likelihood that I will do so poorly, so hopefully someone will see and review .. and come here to find out why I added them. ToolmakerSteve (talk) 21:51, 16 November 2015 (UTC)[reply]

"In layman's terms, given two parties who both know a password" -- no, both this and your understanding are a little off--at no point does the server learn the password. The previous paragraph is much more correct 2601:644:400:1D4B:8605:87FB:3201:AB47 (talk) 23:36, 19 May 2017 (UTC)[reply]

Notability of Implementations

What's the consensus on deciding whether something is sufficiently notable to be listed in the implementations? An edit today by Muir22 (talk · contribs) (an account that's made only three contributions since registering in Jan 2008) adds:

mozilla/node-srp, with 21 watches, 86 stars, 95 commits, 29 forks on Github
opencoff/go-srp, with 1 watch, 8 stars, 5 commits, 2 forks on Github
AddAloner/ALOSRPAuth, with 2 watches, 7 stars, 10 commits, 4 forks on Github

The first one look legitimate, but what about the other two? - Pointillist (talk) 00:32, 14 October 2016 (UTC)[reply]

Reverted Introductory Text

Anonymous user 93.132.170.179's contributions lacked citations despite making new assertions. I found both factual errors (e.g. a man-in-the-middle can only impersonate a server during the registration phase of SRP) and grammatical/style errors (e.g. using "A-Priori" instead of italicizing the Latin term as "a priori") to be sufficient to revert the changes. — Preceding unsigned comment added by Anwynd (talk • contribs) 17:51, 25 November 2018 (UTC)[reply]

Remove "citation needed" for "Skipping the verification steps can be dangerous"

"Skipping the verification steps can be dangerous. In the case where the server sends an encrypted packet first, there is a vulnerability where anyone can get offline password guessing.[citation needed]" About the newly added "[citation needed]", I don't know of a source that isn't me, but it's simple math and I assume it's in the definition (RFC or paper). Here's the simple math:

Given:

Public info: $I$ , u, k, g, s, A, B
Attacker's: a
Server's verifier: Verifier = H(S_Steve) = H(S_Carol) = H((B − kg^x)^{(a + ux)}) or equivalent (e.g. aead(key=H(S_Steve), ...))

Attack:

Make guess at password and generate x = H(s | H( $I$ | ":" | password))
Check Verifier == H((B − kg^x)^{(a + ux)} (Note B, k, g, u are public, a is known to the attacker, and x is guessed) NotSc00bz (talk) 18:52, 4 September 2020 (UTC)[reply]