Jump to content

Talk:Secure Remote Password protocol

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by 71.191.197.79 (talk) at 05:52, 30 June 2011 (Patents?: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
WikiProject iconComputing Unassessed
WikiProject iconThis 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.
???This article has not yet received a rating on Wikipedia's content assessment scale.
???This article has not yet received a rating on the project's importance scale.

Small nitpick: If and both and are prime then (not ) 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

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]

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]