Cleaned up code for rehosting on github
tcocagne
parent
9de5d1a3f9
commit
a791886b2e
40
LICENSE
40
LICENSE
|
|
@ -1,25 +1,21 @@
|
|||
Copyright (c) 2010, Tom Cocagne
|
||||
All rights reserved.
|
||||
The MIT License (MIT)
|
||||
|
||||
Redistribution and use in source and binary forms, with or without
|
||||
modification, are permitted provided that the following conditions are met:
|
||||
* Redistributions of source code must retain the above copyright
|
||||
notice, this list of conditions and the following disclaimer.
|
||||
* Redistributions in binary form must reproduce the above copyright
|
||||
notice, this list of conditions and the following disclaimer in the
|
||||
documentation and/or other materials provided with the distribution.
|
||||
* Neither the name of the Python Software Foundation nor the
|
||||
names of its contributors may be used to endorse or promote products
|
||||
derived from this software without specific prior written permission.
|
||||
Copyright (c) 2013 Tom Cocagne
|
||||
|
||||
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
|
||||
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
|
||||
DISCLAIMED. IN NO EVENT SHALL TOM COCAGNE BE LIABLE FOR ANY
|
||||
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
|
||||
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
|
||||
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
|
||||
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
||||
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
|
||||
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy of
|
||||
this software and associated documentation files (the "Software"), to deal in
|
||||
the Software without restriction, including without limitation the rights to
|
||||
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
|
||||
of the Software, and to permit persons to whom the Software is furnished to do
|
||||
so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,47 @@
|
|||
csrp
|
||||
====
|
||||
|
||||
csrp is a minimal C implementation of the [Secure Remote Password
|
||||
protocol](http://srp.stanford.edu/). The project consists of a single
|
||||
C file and is intended for direct inclusion into utilizing programs.
|
||||
It's only dependency is OpenSSL.
|
||||
|
||||
SRP Overview
|
||||
------------
|
||||
|
||||
SRP is a cryptographically strong authentication
|
||||
protocol for password-based, mutual authentication over an insecure
|
||||
network connection.
|
||||
|
||||
Unlike other common challenge-response autentication protocols, such
|
||||
as Kereros and SSL, SRP does not rely on an external infrastructure
|
||||
of trusted key servers or certificate management. Instead, SRP server
|
||||
applications use verification keys derived from each user's password
|
||||
to determine the authenticity of a network connection.
|
||||
|
||||
SRP provides mutual-authentication in that successful authentication
|
||||
requires both sides of the connection to have knowledge of the
|
||||
user's password. If the client side lacks the user's password or the
|
||||
server side lacks the proper verification key, the authentication will
|
||||
fail.
|
||||
|
||||
Unlike SSL, SRP does not directly encrypt all data flowing through
|
||||
the authenticated connection. However, successful authentication does
|
||||
result in a cryptographically strong shared key that can be used
|
||||
for symmetric-key encryption.
|
||||
|
||||
This library serves as the basis for a compatible Python module called
|
||||
[pysrp](https://github.com/cocagne/pysrp). The
|
||||
[pysrp](https://github.com/cocagne/pysrp) project contains complete,
|
||||
user-friendly API documentation as well as a comprehensive overview of the SRP
|
||||
protocol. As the APIs are virtually identical, the [pysrp
|
||||
documentation](http://pythonhosted.org/srp/) is an excellent reference for
|
||||
understanding this library.
|
||||
|
||||
Usage Example
|
||||
-------------
|
||||
|
||||
```
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
#include <string.h>
|
||||
|
|
@ -97,3 +141,4 @@ auth_failed:
|
|||
|
||||
return auth_failed;
|
||||
}
|
||||
```
|
||||
23
README.txt
23
README.txt
|
|
@ -1,23 +0,0 @@
|
|||
*** OVERVIEW ***
|
||||
|
||||
This library is a straight-forward implementation of the Secure Remote Password
|
||||
protocol version 6a as defined at http://srp.stanford.edu. The API documentation
|
||||
is a little light but it's really just a direct C function for each step in the
|
||||
SRP protocol. The easiest way to learn the library is to simply follow the
|
||||
steps in "example.c"
|
||||
|
||||
There is a compatible Python module at http://code.google.com/p/pysrp that
|
||||
contains complete, user-friendly API documentation. As this library serves
|
||||
as the basis for the C-extension module for pysrp, the APIs are very simmilar
|
||||
so the pysrp documentation is a good reference for understanding this package.
|
||||
|
||||
*** USAGE ***
|
||||
|
||||
While it is certainly possile to create a shared library form of this packge,
|
||||
it's really intended for direct inclusion into the source of using applications.
|
||||
The only dependency srp.c has is on the OpenSSL library.
|
||||
|
||||
*** Compiling the example and test code ***
|
||||
|
||||
gcc -o srp_example example.c srp.c -lssl
|
||||
gcc -o test_srp test_srp.c srp.c -lssl
|
||||
62
TODO
62
TODO
|
|
@ -1,62 +0,0 @@
|
|||
void srp_random_seed( const unsigned char * random_data, int data_length );
|
||||
|
||||
|
||||
In the comments for this function, it recommends providing random data be
|
||||
cryptographically strong. This is probably not true, as cryptographically
|
||||
strong random input might be construed to imply 1 bit of entropy for each bit
|
||||
of input. The actual requirement is that as many bits of entropy are supplied
|
||||
as needed to meet the security needs of the application. So just as important
|
||||
as the quality of the unpredictable bits supplied, is the number of bits.
|
||||
There should be a minimum length recommendation, e.g., 256 bits (or something
|
||||
varying according to the strength of the hash function selected, e.g., if you
|
||||
use SHA-512, consider supplying at least 512 bits of entropy into the seed
|
||||
function to achieve 512-bits of security when using SRP.
|
||||
|
||||
|
||||
static void init_random()
|
||||
|
||||
I noticed there is a hard-coded 256-bit buffer which is used to seed the RNG.
|
||||
Adding to the comment above, you might increase this to match the length of the
|
||||
largest supported hash function. The gettimeofday fall back in the event of no
|
||||
good source of entropy is understandable, but dangerous as it essentially
|
||||
provides no security and does so silently. A warning message, or an explicit
|
||||
flag to set to continue without good randomness might be worth adding. The
|
||||
idea is similar to curl and wget's --no-check-certificate flag. An interesting
|
||||
anecdote: Old versions of Netscape used timeofday to seed its SSL code, which
|
||||
of course enabled anyone to quickly determine the keys that were used.
|
||||
|
||||
void srp_user_delete( struct SRPUser * usr )
|
||||
|
||||
|
||||
It is a common practice when handling passwords to clear the bits before
|
||||
freeing them to prevent other applications from requesting memory and ending up
|
||||
with the password in the newly allocated block. You might consider doing this
|
||||
before the free at line 675. This would apply to any other artifacts produced
|
||||
which incorporate the password deterministically, as they could enable brute
|
||||
force determination of the password.
|
||||
|
||||
void srp_user_process_challenge( struct SRPUser * usr,
|
||||
const unsigned char * bytes_s, int len_s,
|
||||
const unsigned char * bytes_B, int len_B,
|
||||
const unsigned char ** bytes_M, int * len_M )
|
||||
|
||||
|
||||
How big is B in the following:
|
||||
BN_sub(tmp1, B, tmp3); /* tmp1 = (B - K*(g^x)) */
|
||||
I am wondering if K*g^x might exceed the size of B and lead to a negative result.
|
||||
|
||||
If the session keys are considered sensitive information, I would also advocate
|
||||
zeroing them before free.
|
||||
|
||||
|
||||
Note that I did not review everything, and I am not at all familiar with the
|
||||
implementation of SRP, but if it passes compatibility tests, I would be quite
|
||||
confident in its implementation correctness.
|
||||
|
||||
* Consider using stanford's srp demo application to generate some a valid
|
||||
input => output pair to ensure correctness.
|
||||
|
||||
* Consider using a password based key derivation function for generating
|
||||
v (slows down brute-force attempts on compromised servers).
|
||||
|
||||
* Potentially scrypt could be used to prevent GPU-accellerated attacks
|
||||
Loading…
Reference in New Issue