Re: Where do the random numbers come from?

• Previous message: Simon Tatham: "Re: Where do the random numbers come from?"
• In reply to: Simon Tatham: "Re: Where do the random numbers come from?"
• Next in thread: Simon Tatham: "Re: Where do the random numbers come from?"
• Reply: Simon Tatham: "Re: Where do the random numbers come from?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Thu, 10 Feb 2005 11:30:39 +0100

Simon Tatham wrote:
> Bjoern <bjoern_p1@gmx.net> wrote:
>
>>Ah OK, sorry, I guess I confused it with SSL which appears to be the
>>predecessor of TSL? I'll look into ssh... However, the reason I am not
>>just using an established protocol is that resources on my client are
>>limited (mobile phone). The protocols I found are too heavyweight
>
>
> What do you mean by `too heavyweight'? Do you mean you've actually
> tried them and they run too slowly?

Speed is an issue, but more important is memory usage. Also the (java)
application's file size is limited - in one case to 64 KB, and adding
the classes for RSA and AES makes up for 17KB already. I intend to check
if I can optimize the source some more, though - it seems the bulk of
the space is being taken up by the BigInteger class, and I might not
need all of it's methods. Startup time (initializing the encryption) is
also relatively long.

> Which part of the protocol is too slow? You might still gain
> advantage from reusing the rest. For example, if SSH2's
> Diffie-Hellman key exchange is too slow for you, you might still do
> well to substitute an alternative key exchange method but to keep
> the rest of the protocol, since it has carefully thought through a
> great many other things that you'd be unlikely to get right on your
> own.

That's what I am trying to do, I said 'mimicking' because I only use
parts of the protocol. I guess there is no problem with AES, what is
really taking most of the time and memory appears to be the BigInteger
operations, required for asymmetric encryption.

> (There is no `f' in `authentication'. You are making sure that
> somebody is authentic, therefore you are authentic-ating them.)

Ooops, very embarassing, thanks for pointing that out!

>>but it seems to me that it takes only 5 minutes to compute an 8
>>letter password, if you have the hash of login and password - so it
>>is not secure at all.
>
>
> Where do you get this figure from? I don't understand your reasoning
> at all. Given an eight-character password, you have perhaps 90
> possible choices for each character, so your search space is 90^8
> possible passwords, which is 4304672100000000. If you have a machine
> that can do that many hash operations in five minutes, I want to buy
> it from you!

Thanks again - I was only testing with digits, which is what some of
companies use (passwords that consist only of digits). But it's
reassuring to know that using more characters increases the computing
time so significantly, I should have tried that myself :-/

> The more interesting problem with HTTP Digest is that it contributes
> nothing towards the security of the session. Partly this is in
> confidentiality: HTTP Digest protects your password from an
> eavesdropper but the subsequent data you transfer once authenticated
> is readable. But more importantly, the major threat it leaves open
> is session hijacking: once you've done the exchange of digests and
> the server is convinced of your identity, a malicious attacker in
> between you and the server can suddenly insert their own data into
> your network connection and send their own commands, which will be
> executed by the server in the assumption that they've come from you.

Wouldn't it be possible to create a hash over all the commands, not just
the password, though?

> This is not a theoretical risk. One of the computers I use was
> subjected to a real session hijacking attack a few months ago.
> (Fortunately, we were using SSH and therefore the host key mechanism
> detected it immediately.)

I believe you, I think hacking attacks are a very real threat,
especially as they are often beind conducted automatically. So it is not
  an issue of being an interesting victim or having enemies.

>>The library just provides the algortithms, though, it is up to me to put
>>them together. I am asking here because I never read anything about the
>>random number generation in any of the protocol specifications I found.
>>Of course you can seed the BouncyCastle random number generator with
>>anything you want.
>
>
> Random number security is not just a matter of where you get your
> seed data from (although that is important, of course). Another
> important consideration is whether the random number generator's
> internal state can become known.
>
> For example, the best-known random number generator used for non-
> cryptographic purposes is a linear congruential one, in which each
> output of the generator is derived from the previous output by a
> simple mathematical formula. This means that if you used it in a
> hostile environment, an attacker who could see just one _output_
> from your generator would be able to predict all the subsequent
> outputs without even needing to try to guess your initial seed.

I have to check the BouncyCastle algorithm (which is based on SHA1), but
since they go at lenghts to provide a SecureRandom class rather than
just Random, I think they have taken this into consideration.

Many thanks for your comments!

Bjoern

• Previous message: Simon Tatham: "Re: Where do the random numbers come from?"
• In reply to: Simon Tatham: "Re: Where do the random numbers come from?"
• Next in thread: Simon Tatham: "Re: Where do the random numbers come from?"
• Reply: Simon Tatham: "Re: Where do the random numbers come from?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]