Re: SRP with poor randomness on the host

From: karl malbrain (malbrain_at_yahoo.com)
Date: 11/26/05 

Date: 26 Nov 2005 11:29:14 -0800

Erik Corry wrote:
> Hi
>
> I have an application where I want secure login on a variety of
> small systems, some of which have difficulty in obtaining good
> sources of randomness.
>
> (I plan to use SRP-6 with a randomly generated password (ahead of
> time). Since dictionary attacks against sufficiently large random
> passwords are infeasible I plan to omit the salt from the algorithm.

Are you planning to store the randomly generated password on the small
system instead of having the user enter the password? If so, the
security on that client will be compromised.

> It may be that without the requirement of user-memorably passwords
> I should be using a different protocol to SRP. What I like about SRP
> is the property that the verifier stored on the host cannot be used
> to gain access to other hosts. In my scenario there is a large
> number of hosts. Also the fact that a session key drops out of the
> successful SRP exchange is useful.)
>
> But:
>
> It appears to me that if an eavesdropper can guess b that means they can
> obtain v and S, and thus they can obtain the session key.

Who is having the trouble generating the random numbers? You say above
that it is the client, but b is the server's random number; a is the
client's random number in the SRP protocol.

> Since the
> value of M1 can be used to validate a guess of b it is possible to
> do an offline search of likely values of b, enabling an eavesdropper to
> compromise the confidentiality of a session. If b (and thus S and
> the session key) are found quickly (while the connection is still
> active) then the integrity of the connection can also be attacked.
>
> I am not too worried about leaking v, since SRP is reasonably resistent
> to v being known, but I am considering adding a second random shared
> secret over and above the 'password' to be deposited in verbatim on
> both the host and the client. This would be used with S as input to
> the hash that creates the session key, and would prevent a mere eavesdropper
> from obtaining the session keys.
>
> Does this make sense?

Again, anything you store on the client makes it vulnerable if the
client is compromised. Your addition doesn't seem to offer any
additional security. You're going to need some kind of random number.
 karl m

Relevant Pages

  • SRP with poor randomness on the host
    ... I should be using a different protocol to SRP. ... and thus they can obtain the session key. ... both the host and the client. ... from obtaining the session keys. ...
    (sci.crypt)
  • RE: SSL and IPS (was RE: ssh and ids)
    ... need is the private key of one party (provided here by key escrow, ... > session key, they still won't have the next session key. ... > cryptography here, folks... ... >> key for client certs too. ...
    (Focus-IDS)
  • Re: RSA padding
    ... > I was assuming integrity protection as part of the message, ... Client encrypts the byte string using twofish, ... Have you looked at SRP? ... not using any add-on libraries. ...
    (sci.crypt)
  • KDC failover
    ... The client sends a request to the AS requesting a TGT. ... a session key that will be used by the client to communicate with ... if the KDC that granted the TGT ... the session key that the client uses to encrypt the request, ...
    (comp.protocols.kerberos)
  • Re: Determining IsInRole over a VPN
    ... The SRP stuff gives you secure auth of pw without passing any ... LoginUser at the server side. ... the client and server and what auth database your using ... >>> The application is a rich client that accesses a backend over the VPN. ...
    (microsoft.public.dotnet.security)